Hi Levente,

> On Jan 17, 2016, at 7:30 AM, Levente Uzonyi <leves@caesar.elte.hu> wrote:
>
>> On Sat, 16 Jan 2016, Eliot Miranda wrote:
>>
>> On Sat, Jan 16, 2016 at 4:37 PM, Levente Uzonyi <leves@caesar.elte.hu> 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