[Vm-dev] re: Can OSProcess functionality be implemented using FFI
instead of plugin?
kilon.alios at gmail.com
Mon Jan 18 13:16:29 UTC 2016
ah ok now its crystal clear thanks for the explanation.
On Mon, Jan 18, 2016 at 3:11 PM Eliot Miranda <eliot.miranda at gmail.com>
> Hi Dimitris,
> On Jan 18, 2016, at 4:11 AM, Dimitris Chloupis <kilon.alios at gmail.com>
> AFAIK OS thread are capable of being assigned to multiple cores thus
> offering real concurency, thus I presume your native threads are not OS
> threads. So the VM run on one thread but can communicate with other threads
> ? Does that apply to multithreaded VM ?
> As I said these /are/ native OS threads. The VM arranges that only one
> native thread can run the VM at any one time. The owning thread locks out
> other threads. The VM makes an FFI call out on one OS thread which unlocks
> the VM just before calling out and if that callout takes enough time for
> the heartbeat thread to beat then another thread will be released to try
> and lock and run the VM. If it wins the race the other call out thread
> will block when trying to rhea quire the VM to return it's result.
> So this is real multi threading without concurrency as I said.
> On Mon, Jan 18, 2016 at 2:02 PM Eliot Miranda <eliot.miranda at gmail.com>
>> Hi Dimitris,
>> On Jan 18, 2016, at 3:29 AM, Dimitris Chloupis <kilon.alios at gmail.com>
>> so I assume that means callbacks from inside C threads works fine which
>> make it more than enough at least for now.
>> C threads us a misnomer. Callbacks from native threads that are
>> currently calling out work. I /think/ callbacks from native threads that
>> have previously called out but are not currently calling out work, but am
>> not sure. Callbacks from native threads the VM has not seen before don't
>> yet work; the VM doesn't service them.
>> Does that mean that the VM will implement a real threading mechanism ?
>> This is a mechanism that allows one to freely share the VM between
>> arbitrary native threads but only one thread can run the VM at any one
>> time. So it provides true multi threading but it does /not/ provide
>> On Mon, Jan 18, 2016 at 1:11 PM Craig Latta <craig at netjam.org> wrote:
>>> > ...when Craig Latta tried to use [Alien FFI] 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.
>>> (Yes, it seemed close enough that I spent several hours debugging,
>>> trying to get it the rest of the way. I ran out of time, so I wrote a
>>> wrapper C library around the one I wanted to use, with threaded C
>>> callback functions that signalled Smalltalk semaphores on which my
>>> synchronous-FFI Smalltalk process waited. A hack, but it worked fine and
>>> was simple.)
>>> Craig Latta
>>> +31 6 2757 7177 (SMS ok)
>>> + 1 415 287 3547 (no SMS)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev