On Fri, 10 May 2013 13:41:31 -0400, you wrote: >On 10 May 2013 13:34, Steven McCoy <steven.mc...@miru.hk> wrote: > >> That would require a special version of zmq_poll that effectively >> implements a fiber scheduler: wake up the correct fiber based on pending >> socket data. >> >> >That's a third option: > >1: Dumb polling per fiber. >2: Fiber-aware zmq_poll API. >3: Fiber-aware zmq_recv API. > >By 0mq nature one does not need zmq_send to be fiber-aware.
I'm not sure I get it why the zmq API needs to be aware of the fibers? I believe one could use zmq_recv with the status of ZMQ_NOBLOCK. I recently discovered that, and I think it was the missing piece I was looking for. If there is a message in the queue, we simply fetch the message, and pass that message to the Fiber that is waiting for it, and execute that Fiber. If the message queue is empty (EAGAIN), then you create more Fibers to do more things. Those new Fibers will end up yielding at some point (when it needs IO/network/etc), at which time it switches back to the main loop to see if there are any new messages we can process or if we need to create some more Fibers to do more work. This worker thread, is always in the context of a single ZMQ socket and a single operating system thread. Correct me if I'm wrong, but in this way ZeroMQ could support this without any modification at all? It seems rational to me but I'm just sounding out my ideas to see if there is anything inherently wrong with it. Ian _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
