agree@carltonfields.com wrote:
How, then, does the calling/signalling prim-code communicate parameters to the callback?
From the "The Do-It-Yourself Guide to Squeak Primitives"
(http://www.create.ucsb.edu/squeak/DIYSqPrims.html) --
"You can also trigger Smalltalk semaphores from C primitives; see John Maloney's SoundPlayer class or Siren's PrimMIDIPort for examples. This is by far the best way to implement "call-backs" from C to Smalltalk--have the Smalltalk application class pass down a semaphore to the VM and then start a loop process that waits for the semaphore and handles it asynchronously (If you're really clever, you can even create events and post them in Squeak's event input queue.)"
The way I "pass arguments" is to have the data cached in the VM, and have the waiting process make another "fetch" prim call. In the case of the MIDIPort input, the code outline looks like the following:
On start-up (port open), call a prim. and pass it a semaphore number (that's registered as external) Start a wait process in Smalltalk that waits on that semaphore At some later time (in response to a primitive or to external activity), signal the semaphore from the VM. The Smalltalk wait process makes a prim. call to get some data and waits again
squeak-dev@lists.squeakfoundation.org