[racket] sync on OS semaphore on Unix

On 07.02.2012, at 00:35, Matthew Flatt wrote:

> While calling most scheme_...() function is out, can the real-time
> thread call scheme_signal_received(), which amounts to a write() on an
> native OS pipe?

Unfortunately not. On Linux, this would work well, because the "footprint" of a write() to a pipe is very small, but on QNX, where we especially have the demand for threads running in hard realtime (jitter < 10us), definitely not: as a micro-kernel OS, QNX implements pipes as a separate process,  so writing to a pipe means scheduling to another process with its problems like scheduling jitter and priority inheritance ... 

But, a while ago you had conservation with John Clement about the mzrt_sema_post call (which seem internally be realized using condition variables and, hence, be OK on QNX). Might this call be a way to wake up the racket main thread instead of scheme_signal_received()?

> If not, I think we'll need a new OS thread at some level to convert a
> semaphore wait to a call to scheme_signal_received(). The main Racket
> thread on a Unix platform sleeps via epoll(), poll(), or select(), all
> of which need file-descriptor activity to wake up (I think).

If mzrt_sema_post is no alternative, I will have to add one additional OS thread, which is waked up by, e.g., a condition variable and then polls all OS semaphores for all communications of the C threads with the racket main thread. This way, only one OS thread is enough (and not one for each semaphore as I thought yesterday).



> At Tue, 7 Feb 2012 00:11:51 +0100, Berthold Baeuml wrote:
>> Is there a "canonical" way to make a native OS semaphore (Unix), set from an OS 
>> thread, into a racket syncable event? The use case I have in mind is a racket 
>> program which starts a native OS thread for realtime execution of a C loop. 
>> This OS thread sets a OS semaphore to signal that some data is ready for being 
>> taken by the racket side. A racket thread should now be able to somehow sync on 
>> this OS semaphore. Important fact is that the OS thread has to fulfill (hard) 
>> realtime constraints and, hence, is not allowed to call any scheme_... 
>> functions of the racket C-API with non-deterministic  execution time. Moreover, 
>> I do not want to have an additional OS thread (with non-realtime constraints, 
>> then) for translating the event to the racket side, because this will give a 
>> lot of "thread clutter, e.g. in with the ps command". A perfect solution would 
>> be to do it completely with the ffi-module and not having to fall back to the 
>> racket C-API. 
>> 
>> All the best,
>> Berthold
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ____________________
>>  Racket Users list:
>>  http://lists.racket-lang.org/users