Fibrils and asynchronous system calls [LWN.net]

Fibrils and asynchronous system calls

Posted Feb 1, 2007 11:48 UTC (Thu) by simlo (subscriber, #10866)
Parent article: Fibrils and asynchronous system calls

It reminds me of call/cc in functional programming, which can be used to emulate volentary preemption. Using such a mechanism is much easier than making explicit state machines.

Having several fibrils per thread could be used event handling as well:
Interfaces often contain callbacks on which the user of a subsystem can get function executed on a special event. In multi-threaded environments this is hazardeous due to deadlocks. However, if the callback can be executed in a fibril in the user's thread instead of originating thread, you can avoid deadlocks and maybe even the need for a lock in the first place. (A fibril should not be allowed to run if the thread owns a mutex. Does the sample patch take care of that?).
That would in fact be a message passing system, which is really, really usefull for many applications. I am not a huge fan of message parsing systems, but I think the technique has it's places.

(Log in to post comments)

Fibrils and asynchronous system calls

Posted Feb 2, 2007 2:27 UTC (Fri) by pimlott (guest, #1535) [Link]

It reminds me of call/cc in functional programming

Bingo, I was hoping someone would say that. The functional world has some nice mechanisms for handling concurrency. For example you can express an IO operation as a description of the request, plus a function to run on the result (and this is natural with lambda and lexical closure). The runtime can manage all outstanding requests and pass the responses to the functions as they become available. Similarly, a driver can be expressed as a computation that returns either an answer, or a message indicating what resource it needs before it can continue, plus a function to run on that resource. The runtime again obtains the needed resources and runs the continuations. You get most of the benefit of event-driven programming, with the illusion of sequential processing (outside the runtime).

I'm reminded of Alan Cox's quote, "Computers are state machines. Threads are for people who can't program state machines." To which the best programmer I've ever known answered, "I can't program state machines!" The appearance of sequential execution is a boon to programmer productivity.