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