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 ____________________ Racket Users list: http://lists.racket-lang.org/users
