[Vm-dev] FFI callbacks

John McIntosh johnmci at smalltalkconsulting.com
Tue Nov 25 17:22:49 UTC 2014

Look at the squeak proxy logic, I put in the objective-c work


But if you where to reverse that, where the vm would assemble the request,
pop back to the JS environment, which execute the request, then return to
the VM.

On Tue, Nov 25, 2014 at 4:18 AM, Bert Freudenberg <bert at freudenbergs.de>

> On 25.11.2014, at 03:19, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Bert,
> On Mon, Nov 24, 2014 at 2:49 PM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
>> How do they actually work? I want to know what information the thunk
>> needs, and what happens when it is activated. I think SqueakJS would
>> benefit from callback support.
> I'll try and write this up properly in a blog post tomorrow.  But...
> Callback is a [...]
> Cool, very interesting! Thanks :)
> Provided that the callback occurs from the context of a callout there are
> no problems.  Threaded callbacks take some more doing.  Basically the VM
> needs to b sharable between threads.  This is the threaded VM prototype.
> If you absolutely need threaded callbacks we should have a serious talk.
> This is not trivial to productise.
> I absolutely need callbacks that happen after the method returned.
> JavaScript uses callbacks for everything, because it is single-threaded.
> There is no preemption, and not even a yield: you always have to return
> completely back to the browser. You don't call the browser, it calls you.
> There is no main(). Also, there is no longjmp.
> The whole SqueakJS VM is implemented as a callback. When it is called, it
> executes bytecodes for a couple of milliseconds, arranges to be called back
> again soonish, and returns. This is pretty easy to do with a plain
> interpreter, but makes it harder to do a proper JIT. But the JIT will have
> to support this model one way or another (mine does).
> Good news is that the VM is always in a consistent state, it can only be
> observed between bytecodes, not while it is in the middle of something.
> So inside an FFI callback the thunk automatically owns the VM. It can just
> execute bytecodes until the return-from-callback primitive was invoked
> (which would set a flag). This is how e.g. my clipboard code works: The
> copy callback puts a cmd-c keyboard event in the image's queue, then runs
> the VM until the image has invoked the clipboard primitive (which stores
> the clipboard data and sets a flag), then returns the clipboard data.
> The question is, how do I switch to the FFI callback's context. I think
> this should work like a process switch, as if the current process was
> pre-empted by a higher-priority process. I could make it work in the image
> I guess - just launch a high-priority process executing the callback block
> in an endless loop, and have it wait on an external semaphore. The thunk
> would signal the semaphore and execute bytecodes until the return prim was
> called, or it's blocked on the semaphore again, then return.
> Maybe this would be the cleanest solution. What I don't like about it is
> that I would have to manually manage Squeak processes. There is no way to
> know how often the callback will be executed, so I fear that gazillions of
> callback processes would clutter up the image. If instead the thunk would
> create the process when needed, it would automatically go away when the
> callback is no longer used. OTOH this would make the block and process not
> be part of the object memory anymore ... not sure yet if this would be good
> or bad. Also, creating processes is normally done in the image, not in the
> VM. Might not be a good idea.
> Overall these design constraints are pretty different from a regular C VM.
> OTOH the Android VM works in a similar way, being callback-based and
> single-threaded, right? Not sure about iOS - does the ObjectiveC bridge
> support callbacks?
> Ideas welcome :)
> - Bert -

John M. McIntosh <johnmci at smalltalkconsulting.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141125/53c6b79a/attachment-0001.htm

More information about the Vm-dev mailing list