You should set up an evt through the C API using scheme_add_evt(), where the evt's polling function checks something to be set by the MIDI callback. In addition, the MIDI callback should call scheme_signal_received() (ok to call from any OS-level thread or signal handler) to ensure that the evt's polling operation is called by the runtime system.
At Tue, 20 Apr 2010 11:08:23 -0700, John Clements wrote: > Justin Phillips is writing code to allow Racket[*] to interact with Mac OS X > MIDI events. This OS code has the following interface, as I understand it: > give me a callback, and I'll set up a new high priority thread to receive > calls to this callback. > > Unfortunately, as we understand it, having a separate thread call racket code > is a big no-no. > > So, we have two threads running in the same process, needing to communicate. > Ideally, we'd like to avoid polling, but I'm not sure what the best strategy > is. Is there an obvious choice for allowing a C thread to send a signal > (perhaps just a Unix 'signal'?) to the racket threads? Could the C code > manipulate a racket semaphore? I pawed through Inside PLT Scheme for a bit, > but didn't find what I was looking for. > > Suggestions and doc pointers much appreciated, > > John Clements > > > > > > [*] When should we start calling it "racket" on plt-scheme? The only reason > I > sent this message to plt-dev and not to plt-scheme was because I wasn't sure > about the answer to this question. > ------------------------------------------------------------------------------ > [application/#f "smime.p7s"] [~/Desktop & open] [~/Temp & open] > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
