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

[Mariano Martinez Peck]

Hi Eliot,

Ok, I started from the first step and I am able to type a C program that
would export the STON I need.
This is all hardcoded for the moment and not autogenerated.
The question I have now is....do you think I should use "cmake" for
managing the compilation of this C program (later to be autogenerated) ???
If not, what other choice I have?

Thanks!



On Mon, Jan 18, 2016 at 10:16 AM, Dimitris Chloupis <kilon.alios at gmail.com>
wrote:

>
> 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)
>>>>
>>>>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160120/522f7455/attachment.htm