Re: [Pharo-project] [Vm-dev] Re: Can OSProcess functionality be implemented using FFI instead of plugin?
Locked
Re: [Pharo-project] [Vm-dev] Re: Can OSProcess functionality be implemented using FFI instead of plugin?
 
|
On Sat, Jan 16, 2016 at 4:37 PM, Levente Uzonyi <[hidden email]> wrote:
This presupposes the threaded FFI. The threaded FFI allows the VM to make any number of blocking calls, adding a new thread to run the VM whenever the VM is stalled when the heartbeat beats. hence one can freely read and write to/from i/o blocking i/o streams (including pipes and sockets) or blocking database connexions, etc, all without stating that the FFI call must be done in a special way, since all calls through the FFI can block without blocking the VM. Note that the scheme is also amenable to plugins, but the plugins must be rewritten to include the release vm/acquire vm calls around a blocking call. With the threaded VM the FFI includes these calls around every FFI call. HTH _,,,^..^,,,_ best, Eliot |
Re: [Pharo-project] [Vm-dev] Re: Can OSProcess functionality be implemented using FFI instead of plugin?
|
|
On Sat, 16 Jan 2016, Eliot Miranda wrote:
> > > On Sat, Jan 16, 2016 at 4:37 PM, Levente Uzonyi <[hidden email]> wrote: > > On Sat, 16 Jan 2016, Mariano Martinez Peck wrote: > > (Still no quote.) > > How will you read the output of the process without having your image's process blocked in the FFI callout? > How will you make sure that writes to input of the process won't block the FFI callout? > > > This presupposes the threaded FFI. The threaded FFI allows the VM to make any number of blocking calls, adding a new thread to run the VM whenever the VM is stalled when the heartbeat beats. hence one can freely read and write to/from i/o blocking i/o streams > (including pipes and sockets) or blocking database connexions, etc, all without stating that the FFI call must be done in a special way, since all calls through the FFI can block without blocking the VM. FFI was not production ready. Is it ready for produciton now? Levente > > Note that the scheme is also amenable to plugins, but the plugins must be rewritten to include the release vm/acquire vm calls around a blocking call. With the threaded VM the FFI includes these calls around every FFI call. > > HTH > _,,,^..^,,,_ > best, Eliot > > |
Re: [Pharo-project] [Vm-dev] Re: Can OSProcess functionality be implemented using FFI instead of plugin?
|
|
Hi Levente,
> On Jan 17, 2016, at 7:30 AM, Levente Uzonyi <[hidden email]> wrote: > >> On Sat, 16 Jan 2016, Eliot Miranda wrote: >> >> On Sat, Jan 16, 2016 at 4:37 PM, Levente Uzonyi <[hidden email]> wrote: >> >> On Sat, 16 Jan 2016, Mariano Martinez Peck wrote: >> >> (Still no quote.) >> >> How will you read the output of the process without having your image's process blocked in the FFI callout? >> How will you make sure that writes to input of the process won't block the FFI callout? >> This presupposes the threaded FFI. The threaded FFI allows the VM to make any number of blocking calls, adding a new thread to run the VM whenever the VM is stalled when the heartbeat beats. hence one can freely read and write to/from i/o blocking i/o streams >> (including pipes and sockets) or blocking database connexions, etc, all without stating that the FFI call must be done in a special way, since all calls through the FFI can block without blocking the VM. > > I think it was you who said (in a discussion with Craig) that the threaded FFI was not production ready. Is it ready for produciton now? No, but I expect this is the year it will be. Spur provides pinning, so the VM infrastructure is there. The Pharo community plus some commercial relationships that have developed are providing funding. Esteban Lorenzano and I want to collaborate on this and I hope to get help from some other people, such as Ronie Salgado. And Mariano is working on an important part of the problem. So I feel there's sufficient momentum for us to realize the threaded FFI this year. > Levente _,,,^..^,,,_ (phone) >> Note that the scheme is also amenable to plugins, but the plugins must be rewritten to include the release vm/acquire vm calls around a blocking call. With the threaded VM the FFI includes these calls around every FFI call. >> HTH >> _,,,^..^,,,_ >> best, Eliot |
Re: [Pharo-project] [Vm-dev] Re: Can OSProcess functionality be implemented using FFI instead of plugin?
|
wow impressive work guys , thats awesome news. On Sun, Jan 17, 2016 at 6:53 PM Eliot Miranda <[hidden email]> wrote:
|
Re: [Pharo-project] [Vm-dev] Re: Can OSProcess functionality be implemented using FFI instead of plugin?
|
|
In reply to this post by Eliot Miranda-2
> On Jan 17, 2016, at 8:53 AM, Eliot Miranda <[hidden email]> wrote: > > Hi Levente, > >>> On Jan 17, 2016, at 7:30 AM, Levente Uzonyi <[hidden email]> wrote: >>> >>> On Sat, 16 Jan 2016, Eliot Miranda wrote: >>> >>> On Sat, Jan 16, 2016 at 4:37 PM, Levente Uzonyi <[hidden email]> wrote: >>> >>> On Sat, 16 Jan 2016, Mariano Martinez Peck wrote: >>> >>> (Still no quote.) >>> >>> How will you read the output of the process without having your image's process blocked in the FFI callout? >>> How will you make sure that writes to input of the process won't block the FFI callout? >>> This presupposes the threaded FFI. The threaded FFI allows the VM to make any number of blocking calls, adding a new thread to run the VM whenever the VM is stalled when the heartbeat beats. hence one can freely read and write to/from i/o blocking i/o streams >>> (including pipes and sockets) or blocking database connexions, etc, all without stating that the FFI call must be done in a special way, since all calls through the FFI can block without blocking the VM. >> >> I think it was you who said (in a discussion with Craig) that the threaded FFI was not production ready. Is it ready for produciton now? > > No, but I expect this is the year it will be. Spur provides pinning, so the VM infrastructure is there. The Pharo community plus some commercial relationships that have developed are providing funding. Esteban Lorenzano and I want to collaborate on this and I hope to get help from some other people, such as Ronie Salgado. And Mariano is working on an important part of the problem. So I feel there's sufficient momentum for us to realize the threaded FFI this year. and when Craig Latta tried to use it late last year it worked up to a point. The thing that didn't work was callbacks from foreign threads. So it looks like the core threading code is not too far away from working. Another really important part, bigger than threading, is marshaling. Being able to handle the full x85_64 abi requires a better approach than interpreting tops signatures. Igor's NativeBoost gave an example of how to generate marshaling machine code, but alas only for x86. But Sista includes an extensible bytecode set for arbitrary instructions. Sista is close to production, and we know the bytecode set works. So the plan is to use these bytecodes to do the marshaling. That neatly solves the problems of a) associating marshaling machine code with a method and b) marshaling in an interpreted stack VM, since the bytecode set works in any Cog VM. So the plan is to write an ABI compiler from C signatures to marshaling code to replace the interpreted FFI plugin. So this year I hope we will have an excellent high performance FFI. >> Levente > > _,,,^..^,,,_ (phone) > >>> Note that the scheme is also amenable to plugins, but the plugins must be rewritten to include the release vm/acquire vm calls around a blocking call. With the threaded VM the FFI includes these calls around every FFI call. >>> HTH >>> _,,,^..^,,,_ >>> best, Eliot |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |