<div dir="ltr">Look at the squeak proxy logic, I put in the objective-c work <div><br></div><div><a href="https://drive.google.com/file/d/0BzM4orHA3iGxMjU0ZDU4MWEtOTQ2Zi00OGVlLTg2ODUtYzU1MTFhYzk2ZmFi/view?usp=sharing">https://drive.google.com/file/d/0BzM4orHA3iGxMjU0ZDU4MWEtOTQ2Zi00OGVlLTg2ODUtYzU1MTFhYzk2ZmFi/view?usp=sharing</a><br><div><br></div><div>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. </div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 25, 2014 at 4:18 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div style="word-wrap:break-word">On 25.11.2014, at 03:19, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br><div><blockquote type="cite"><br><div><div dir="ltr">Hi Bert,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 24, 2014 at 2:49 PM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br>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.<br></blockquote><div><br></div><div>I'll try and write this up properly in a blog post tomorrow. But...</div><div><br></div><div>Callback is a […]</div></div></div></div></div></blockquote><div><br></div><div>Cool, very interesting! Thanks :)</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div>
</div></div>
</blockquote><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Ideas welcome :)</div><br><div>
<span style="border-collapse:separate;border-spacing:0px;font-family:'Lucida Grande';font-size:12px"><div style="word-wrap:break-word"><div style="font-family:Helvetica"><span style="font-family:Helvetica">- Bert -</span></div></div></span></div><br></div><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">===========================================================================<br>John M. McIntosh <<a href="mailto:johnmci@smalltalkconsulting.com" target="_blank">johnmci@smalltalkconsulting.com</a>> <a href="https://www.linkedin.com/in/smalltalk" target="_blank">https://www.linkedin.com/in/smalltalk</a><br>===========================================================================<br></div></div>
</div>