4 ms·

Interesting, but a bit light on how to read/write from TCP (as opposed to opening a collection). Would love to see some details about what goes on behind the ho

by norswap 12y ago

Interesting, but a bit light on how to read/write from TCP (as opposed to opening a collection). Would love to see some details about what goes on behind the hood.

simendsjo 12y ago
The documentation for raw TCP might be a bit sparse: http://vibed.org/docs#raw-tcp http://vibed.org/docs#raw-tcp There was a talk on dconf 2013 about vibe: http://dconf.org/2013/talks/panteleev.html http://dconf.org/2013/talks/panteleev.html Notice the slides and video links. It focuses on web development, but you'll get some insight into vibe.d that's valid for TCP too.
sol1684 12y ago
There is a coarse description on the "features" page of how blocking operations in general are handled. The same principle applies to all kinds of blocking operations (waiting for a mutex lock, sleeping, waiting for data on a pipe etc.). http://vibed.org/features#fibers http://vibed.org/features#fibers It still doesn't go into full detail, though, and a dedicated article would probably be worthwhile to write.
etcimon 12y ago
The coroutines (fibers/tasks) work in the same way threads do in a kernel. Vibe.d is a reimplementation with something called "fibers", with task-messaging, task contexts, context switching. When using poll or select kernel functions, your thread "yields" and allows other processes to do some work while your process waits for i/o data. Fibers work the same way but the waiting happens within your process. Basically, when all fibers are waiting, there's going to be events in the kernel (using epoll or iocp) with the associated fiber pointer to wake it up when something comes up. The fiber (aka task) is called with Fiber.call() when there's news and automatically restores its stack and context, but maybe it has more data in the circular buffer or the manual event you were waiting for was triggered, so the routine can go forward (otherwise, Fiber.yield() is called again and waits for an event from the kernel). This allows the code to stay linear somewhat. Low-level buffers are all meant to yield when data is not available. Every time a new connection happens, a new fiber is created, same goes when you call runTask.

by norswap 12y ago

Interesting, but a bit light on how to read/write from TCP (as opposed to opening a collection). Would love to see some details about what goes on behind the hood.

simendsjo 12y ago

The documentation for raw TCP might be a bit sparse: http://vibed.org/docs#raw-tcp http://vibed.org/docs#raw-tcp There was a talk on dconf 2013 about vibe: http://dconf.org/2013/talks/panteleev.html http://dconf.org/2013/talks/panteleev.html Notice the slides and video links. It focuses on web development, but you'll get some insight into vibe.d that's valid for TCP too.

sol1684 12y ago

There is a coarse description on the "features" page of how blocking operations in general are handled. The same principle applies to all kinds of blocking operations (waiting for a mutex lock, sleeping, waiting for data on a pipe etc.). http://vibed.org/features#fibers http://vibed.org/features#fibers It still doesn't go into full detail, though, and a dedicated article would probably be worthwhile to write.

etcimon 12y ago

The coroutines (fibers/tasks) work in the same way threads do in a kernel. Vibe.d is a reimplementation with something called "fibers", with task-messaging, task contexts, context switching. When using poll or select kernel functions, your thread "yields" and allows other processes to do some work while your process waits for i/o data. Fibers work the same way but the waiting happens within your process. Basically, when all fibers are waiting, there's going to be events in the kernel (using epoll or iocp) with the associated fiber pointer to wake it up when something comes up. The fiber (aka task) is called with Fiber.call() when there's news and automatically restores its stack and context, but maybe it has more data in the circular buffer or the manual event you were waiting for was triggered, so the routine can go forward (otherwise, Fiber.yield() is called again and waits for an event from the kernel). This allows the code to stay linear somewhat. Low-level buffers are all meant to yield when data is not available. Every time a new connection happens, a new fiber is created, same goes when you call runTask.