[racket] sync on OS semaphore on Unix

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Mon Feb 6 18:35:57 EST 2012

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?

If so, then I can explain the way forward.

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).

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

Posted on the users mailing list.