[erlang-questions] driver asyncronous notifications

[Serge Aleynikov]

Oscar Hellström wrote:
>> <quote>
>>  >> One possibility is to create a pipe and
>>  >> register a read-end of the pipe with Erlang's select loop by calling
>>  >> driver_select() function, and use write() call on the other end of
>>  >> the pine from another thread to communicate some activity, so that if
>>  >> would trigger the ready_input() driver's callback in the context of
>>  >> emulator's thread.  However this is a very expensive solution which I
>>  >> wouldn't want to use.
>> </quote>
> 
> I should really learn to think before I speak as well as read before I 
> reply...

And I should learn to proof-read my own posts before clicking "send" to 
eliminate apparent spelling typos.  ;-)

>> The problem here is that pipe is a very expensive way of doing 
>> inter-thread communications.  I implemented this approach and wasn't 
>> happy with performance (that involved two context switches and an 
>> expensive select() call for messages communicated to the emulator's 
>> thread).  I wish that there was something much more light-weight to 
>> notify emulator's thread of an external non I/O related event.
> 
> Have you compared the performance loss to that of a port driver? A port 
> driver would also have to communicate through a pipe, but the 
> synchronisation issues should be gone. Also, the emulator should be able 
> to use kernel polling the fd:s I guess.

Well, in this case I haven't.  However I intuitively think that 
performance would be much (5-10 times?) worse in case of a port process 
because it would have to marshal *all* data through a pipe vs. in a 
driver case just at most one byte per message on the writing end (by the 
signaling thread) and reading everything accumulated on the pipe at the 
reading end (by the emulator thread's ready_input() callback) while 
passing the actual data using an in-memory data structure guarded by a 
mutex.

Serge