Saturday, November 24, 2007
Mixing a Wasp VM With Threaded Applications
My driving problem for Wasp has a GUI written in Qt. Like most GUI libraries, Qt is callback-happy, and expects to be the outer loop for the application; to get around this, I need to let the Wasp Virtual Machine run as its own thread, and use channels to bridge between the two.
Since Wasp is not designed to be terribly friendly to native OS threads, with quite a few global variables in the Virtual Machine, I have added two C functions that pause the VM and resume it: wasp_seize_vm( ) and wasp_release_vm( ), respectively.
These two functions wrap a simple mutex that is locked while the inner Wasp process loop is running, and released momentarily when Wasp is transitioning from one process to another. The GUI application uses wasp_seize_vm( ) to grab control of the GC system, send a message to the event channel, then release control with wasp_release_vm( ). With care, if you squint enough, the threads seem to act like Wasp processes -- as long as you don't touch any Wasp-managed objects.
I use Qt's notifiation APIs in the GUI wrapper library to let Qt know when it needs to do the same.
Vacation's over, time to drive home and start getting ready for work. (As opposed to Wasp, which is still strictly goofing off.)