2012-08-27 13 views
18

¿El código no toma un golpe de eficiencia al ser síncrono? ¿Por qué la codificación es sincrónica una victoria? He encontrado estos dos enlaces en hacer un poco de investigación: http://bjouhier.wordpress.com/2012/03/11/fibers-and-threads-in-node-js-what-for/, https://github.com/Sage/streamlinejs/¿Por qué meteor.js es sincrónico?

Si el objetivo es evitar que el código espagueti, entonces es claro que se puede tener un código asíncrono, con streamline.js por ejemplo, que no es una pirámide de devolución de llamada, ¿derecho?

Respuesta

33

Hay que distinguir dos cosas aquí:

  • funciones sincrónicas como nodo de fs.readFileSync, fs.statSync, etc. Todas estas funciones tienen una Sync en sus nombres (*). Estas funciones son verdaderamente síncronas y bloqueando. Si los llamas, bloqueas el ciclo de eventos y matas el rendimiento del nodo. Solo debe usar estas funciones en el script de inicialización de su servidor (o en los scripts de línea de comandos).
  • Bibliotecas y herramientas como fibras o streamline.js. Estas soluciones le permiten escribir su código en sync-style, pero el código que escriba con ellas seguirá ejecutándose de forma asíncrona. Hacen no bloquean el bucle de evento.

(*) require también está bloqueando.

Meteor utiliza fibras. Su código está escrito en estilo de sincronización, pero no es bloqueante.

El triunfo no depende del rendimiento (estas soluciones tienen sus propios gastos generales, por lo que pueden ser un poco más lentos, pero también pueden funcionar mejor que las devoluciones crudas en patrones de código específicos, como el almacenamiento en caché). La ganancia, y la razón por la cual se han desarrollado estas soluciones, está en el lado de la usabilidad: le permiten escribir su código en estilo de sincronización, incluso si está llamando a funciones asíncronas.

25 Ene 2017 editar: He creado 3 GIST para ilustrar fibras no bloqueante: fibers-does-not-block.js, fibers-sleep-sequential.js, fibers-sleep-parallel.js

+0

"No bloquean el bucle de eventos." La declaración es engañosa ya que las fibras tienen que bloquear el ciclo de eventos en secciones críticas. Depende del desarrollador decidir cuáles son las secciones críticas y utilizar las fibras de forma adecuada. – ashim

+0

@ashim. Esto es incorrecto: las fibras no son preventivas; los cambios de contexto entre las fibras son implementados por libcoro y están completamente desacoplados del bucle de eventos. –

+0

Estoy confundido. Si pongo operaciones de E/S dentro de una fibra, entre los comandos fiber.run() fiber.yield(), el resto del programa esperará hasta que se ejecute esa sección de código. ¿Cómo no está bloqueando? ¿Estoy malentendiendo algo? – ashim

3

El código no es "síncrono" cuando se usa algo como streamlinejs. El código real se todavía se ejecutará de forma asíncrona. No es muy bonito escribir muchas funciones de devolución de llamada anónimas, ahí es donde estas cosas ayudan.