[Vm-dev] re: Can OSProcess functionality be implemented using FFI instead of plugin?

[Dimitris Chloupis]

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>
wrote:

>
> Hi Dimitris,
>
> On Jan 18, 2016, at 4:11 AM, Dimitris Chloupis <kilon.alios at gmail.com>
> wrote:
>
> 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>
> wrote:
>
>>
>> Hi Dimitris,
>>
>> On Jan 18, 2016, at 3:29 AM, Dimitris Chloupis <kilon.alios at gmail.com>
>> wrote:
>>
>> 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
>> concurrency.
>>
>> 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.)
>>>
>>>
>>> -C
>>>
>>> --
>>> Craig Latta
>>> netjam.org
>>> +31   6 2757 7177 (SMS ok)
>>> + 1 415  287 3547 (no SMS)
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160118/1258f977/attachment.htm