> On 16 Oct 2015, at 13:53, Esteban Lorenzano <[email protected]> wrote: > > >> On 16 Oct 2015, at 13:22, Robert Withers <[email protected]> wrote: >> >> Bonjour Stef, >> >> I believe the change everyone would be waiting for is a Multi-threaded VM, >> that supports threaded callouts and callbacks. So I suppose the questions >> become: > > multi thread ffi vm exists as a prototype, and according to its author > (Eliot) needs no less than 4 months of someone skilled working on it to > finish it. > >> - will existing NB syntax require change with the introduction of a MTVM? > > nothing will be equal… why? because you will need to provide callbacks. There > is no magic here, if you want something to happen while doing something else, > you need to provide a way to be called back when that thing finishes. > > now we have: > > nbCall:module: > > to call FFI (will change to a more generic ffiCall:module:, btw… but we’ll > keep old notation some versions to provide backward compatibility) > > So I can imagine an API like this: > > ffiAsyncCall:callback:module: > > So yes… you need change. But that’s inevitable… Of course you can do a fwk > forking in image and starting a continuation, etc. But well, I will let you > guys to think on that (also you still will need the fork) :)
Actually I just remembered that current prototype works attaching external call with an internal Process (with some special id inside). But still, I do not expect call syntax will change at all. Esteban > >> - to what degree will NB syntax need to be extended to support threaded >> callouts. > > as described, I suppose. No exact idea until we implement. > >> - what NB syntax changes are needed for callbacks. > > NB used some magic there. Shadow classes and etc. We do not need/want that > anymore. > > now you have a new FFICallback api, where you can do: > > FFICallback > signature: #(int (int handle, int *pitch, int x, int y, int w, > int h)) > block: [ :handle :pitch :x :y :w :h | > pitch signedLongAt: 1 put: (self get_stride: handle). > self get_data: handle ] > > (I extracted that example from my ongoing port of Athens) > >> - timing: when is MTVM expected and can we operate on the leading edge? > > we are lacking resources: Is just me (in the Pharo part, of course… Eliot and > some others work also in the exclusively VM part, but they have other > agendas). > > So… my plan is: > > - NB to FFI port (should be ready soon) > - spur32 bits (should be ready soon, we are just waiting the NB to FFI) > - spur64 bits (Eliot is working on the JIT, I need to manage the migration of > Pharo) > - FFI 64bits (0% done here… just some stubs waiting for effort). But we want > to move Pharo to 64bits… we are losing a train here... > - FFI MT > > So… not very hight priority. According as how I see things now, I *think* I > can have that some point of 2017… yes, as far as that. Also because I have a > lot other stuff to do, not just the lowlevel parts. > > Of course this is not good and we have talked with some people to speed up > this. We talked with Igor about taking the MT stuff (yes, we also believe is > VERY important), but he fade in the blur… I didn’t hear from him since 3 > months (I’m still waiting for some feedback on OSWindow work he did, he)… yes > I’m a bit frustrated. > > If *anyone* wants to collaborate in any part of this list (is a MASSIVE > effort), I would be very happy and willing to provide as much > assistance/guiding/peer programming as I can. > > hope this helps > > Esteban > >> >> Personally, in SqueakElib, I have my network and session layers working for >> encrypted connections, so I just have the presentation layer to go. Once >> done, I would be very interested in working in the VM with whomever is also >> interested with an eye towards threading (MTVM). I am no expert here so it >> will be a challenge I am looking forward to. >> >> Regards, >> Robert >> >> On 10/16/2015 06:59 AM, stepharo wrote: >>> >>> In pharodays presentations we explictly mentioned our strategy: >>> - we keep NB syntax >>> - we change the assembly generation to be able to get Spur. >>> >>> Stef >>> >>> I can tell you that if I could get a lua kind of jit now I would sign >>> immediately and also for having pharo as a dll. >>> Now it takes time to do soemthing. >>> >>> Le 15/10/15 17:35, Robert Withers a écrit : >>>> >>>> I am reticent to invest in learning FFI that is changing without an idea >>>> of the direction of the change. So >>> >>> >> >
