Comments on: Quelle est la différence entre “bloquer” et “en cours d’exécution” ?

By: foxmask

foxmask — Fri, 12 Dec 2014 20:04:44 +0000

Cool les tampons sont de retour

By: Biganon

Biganon — Wed, 10 Dec 2014 21:35:05 +0000

L’IO compte pas pour des prunes donc (hin hin hin)

By: Alkareth

Alkareth — Wed, 10 Dec 2014 19:09:05 +0000

@Sam : c'est pour quand ?

on bloque en attendant, non pas Godot, mais l’I/O

Merci pour ça, et bon article du reste. Vous avez un certain talent pour clarifier les choses et vulgariser, en un sens. Je suis curieux d'un futur dossier pour la parallélisation, c'est un peu mon dada en ce moment.

By: Sam

Sam — Wed, 10 Dec 2014 14:48:36 +0000

Cet article parle de la prog non bloquante en générale, et tu viens évangéliser GO, et en plus en mélangeant des tas de choses : comment ça marche, des questions de syntaxe, des contextes différents histoire de ne pas pouvoir faire une comparaison juste. Comme un troll emac viendrait sur un article à propos de l'encoding de caractères. Stop. Heureusement qu'on a pas encore restauré les tampons.

By: Pierre Durand

Pierre Durand — Wed, 10 Dec 2014 11:56:02 +0000

Les technologies “non bloquantes” ont 2 intérêts:
– pouvoir facilement à partir d’un point de ton code, lancer plusieurs actions concurrentes, et les “regrouper” plus tard
– pouvoir exécuter de nombreuses requêtes concurrentes sans bloquer un thread (qui est une ressource coûteuse en RAM à cause de la stack)

Le soucis de NodeJS/Javascript, c’est que pour ces 2 points, il utilise des callbacks qui rendent le code illisible.

En Go, c’est différent.
Pour lancer des action concurrentes on utilise le mot clé “go”, et pour synchroniser on peut utiliser de nombreuses techniques comme les channel ou les waitgroup. C’est aussi acrobatique que les callback js, mais je vois mal comment on peut faire autrement.
En revanche, le 2em point est mieux traité en Go qu’en JS.
Dans le cas d’une app web, on peut très bien écrire un code “normal/bloquant”.
Pas besoin de faire de goroutine/channel/waitgroup/”yield”.
(bon OK, c’est le serveur http de GO qui crée des goroutines à la volée pour chaque requête, mais c’est masqué au développeur)
Et le processus utilisera un nombre de thread très réduit.
Je trouve ça plus élégant: on écrit un code “bloquant”, mais il se comporte comme du code “non bloquant”.

By: Sam

Sam — Tue, 09 Dec 2014 20:29:52 +0000

Mais en Go il y a un mécanisme de coroutine et de channels signalées par le mot clé Go qui marque tout ça, donc on retombe dans ce que je disais :

Un outil non bloquant exigera quelque chose pour gérer le retour du résultat plus tard: un callback, une promesse, un yield

Python fait pareil avec yield.

By: Pierre Durand

Pierre Durand — Tue, 09 Dec 2014 19:07:47 +0000

En Go, tu peux très bien faire:
res = faire_operation_sur_IO() faire_un_truc_avec_le_res(res)
pourtant le thread qui l’exécute n’est pas bloqué!

By: Sam

Sam — Tue, 09 Dec 2014 17:43:12 +0000

Non, entre “entre train de bloquer” et “en cours d’exécution”. Le programme n’est pas bloqué, il bloque, activement, et volontairement. C’est une action, pas un état, que je souhaites mettre en avant.

By: Luthaf

Luthaf — Tue, 09 Dec 2014 17:01:34 +0000

Entre bloqué et en cours d’exécution !