RejectedSoftware Forums

Sign up

What happens on block operation?

How runtime detect blocking operation? Is it's some auto-detection or programmer should call yield every time when he expect blocking operation.

Ok, for example we got blocking operation (for example file-reading). The fiber is doing yield. But file reading can't be run in nowhere. It should be run in thread. But where is this thread?

What is the difference between D and Go approche?

Re: What happens on block operation?

On 10/20/17 2:40 AM, Suliman wrote:

How runtime detect blocking operation? Is it's some auto-detection or programmer should call yield every time when he expect blocking operation.

Ok, for example we got blocking operation (for example file-reading). The fiber is doing yield. But file reading can't be run in nowhere. It should be run in thread. But where is this thread?

It works on an event loop. In essence, the fiber is "put to sleep", and
the event library is used to wake it back up when data is ready. All of
it is run in the same thread I believe.

If you are familiar with using select() it looks something like this
(this is my conception anyway, not familiar intimately with the
implementation):

while(true)
{

// run all runnable fibers until yield or registers blocking fd
// with listOfFds
fibers.run();
int fdready;
while((fdready = select(listOfFds, 0)) >= 0) // looks for all file
                                             // descriptors that are
                                             // ready with input
{
   fibers.wakeUpForFD(fdready);
}

}

What is the difference between D and Go approche?

No idea how Go works.

-Steve

Re: What happens on block operation?

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?

As I understand it's not possible to read data without any thread because someone should do reading.

Re: What happens on block operation?

On 2017-10-20 08:40, Suliman wrote:

How runtime detect blocking operation? Is it's some auto-detection or programmer should call yield every time when he expect blocking operation.

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.

On the other hand, if a long running computation is performed, which is
not asynchronous, the whole thread will be blocked until it completes.

Ok, for example we got blocking operation (for example file-reading). The fiber is doing yield. But file reading can't be run in nowhere. It should be run in thread. But where is this thread?

The file operation is queued and performed in the operating system.

What is the difference between D and Go approche?

I would guess Go uses a similar approach.

/Jacob Carlborg

Re: What happens on block operation?

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