On 10/21/17 4:40 AM, Suliman wrote:
and the event library is used to wake it back up when data is ready
But who is complete data-processing? There is some some thread that complete data reading or what?
The OS notifies you when the data is available. Then the fiber is marked
as runnable, and the fiber event loop runs it. It completes the read
while in the context of the only thread of the process.
As I understand it's not possible to read data without any thread because someone should do reading.
There is only one thread. All the fibers share it.
On 10/21/17 9:48 AM, Jacob Carlborg wrote:
The key here for vibe.d is that is to not use blocking operations. For
IO that means using asynchronous IO or non-block IO. That means when
calling "aio_read" or any other asynchronous operation it will
immediately return to the caller. The vibe.d runtime will check if data
is available, if it's not it will yield the fiber to allow other fibers
to run.
Right, but to the user of vibe.d, he doesn't know that it's
non-blocking. As far as the fiber is concerned, the world stopped until
the data came through. This is the huge benefit I see in vibe.d, you can
write code that doesn't care whether the operation is blocking or not,
as it all looks the same.
Really, even a blocking operation isn't truly blocking, the OS just
schedules other processes/threads to run.
-Steve