On Fri, 07 Feb 2014 19:29:27 GMT, Sean Kelly wrote:

On Fri, 07 Feb 2014 19:05:16 GMT, Kelet wrote:

Thank you Sönke and Stefan for the replies!

Before working with vibe.d I was quite into boost::asio which uses the fibers concept also but they're called strands, co-routines and the stack is saved in a yield context and so on. The coroutines can be stackful or stackless. I think it's a nice learning experience to see how they do it as well.

http://www.boost.org/doc/libs/1540/doc/html/boost_asio/overview/core/coroutine.html

One thing I'm not entirely sure of is how vibe.d handles outbound connections. Like say I get a request from the user. This request comes across some client connection and so is backed by its own fiber. Now what if I need to issue a request to some other service while processing this transaction? Any IO on the secondary connection needs to yield and return to that client connection's stack. I imagine vibe.d manages this automatically, but it's a bit further than I've gotten in my own experimentation. I suppose an alternative would be to spawn the outbound connection in its own fiber and use message passing to mediate between them. Then the client connection would block on receive() until that secondary request completes and sends its response.

  • When vibe.d receives a new connection, it picks an unused fiber or creates one. Any fiber that yielded already has some stack data thus aren't candidates to receiving a new connection.
  • When vibe.d receives or sends data from an existing connection, it'll load it in the fiber that owns the connection. Every fiber has an ID number and the connection is attached to this ID, so any activity through this connection will return data to the yielded fiber that owns it.
  • Which brings me to when vibe.d creates a new connection. The ID of the fiber that creates the connection is saved and sent to libevent, which will provide it back to vibe.d through any activity in the callback functions : buffereventsetcb(bufevent, &onSocketRead, &onSocketWrite, &onSocketEvent, cctx); (libevent2.d line 272)

So, the fibers aren't segmented by connection per se ; you'll find it's not limited to 1 connection per fiber.