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

Thu Jan 21 01:07:21 UTC 2016

On Wed, Jan 20, 2016 at 5:33 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
>
>
> On Wed, Jan 20, 2016 at 10:55 AM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>>
>> 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?
>>
>
> Cmake is overkill.  You only have to compile one file with very simple
> flags.  So for now use the old  OSProcess (or compile manually) but... once
> you have your own OSProcess then the right way is to compile it using your
> new OSProcess.  You have to require that the user put the C compiler in
> their path, but everything else you have in the pragmas.  e.g. you're only
> doing
>
> cc -m32 -o MYSQLInterface.mac32 MYSQLInterface.mac32.c
> ./MYSQLInterface.mac32
>
>

Thanks Eliot,

I had the same feeling. Thanks for confirming.

BTW, let me ask...I have already starting coding this so I have to give a
name to the project so that I can create a repo and start committing :)
(even if at the end this is merged in FFI package or whatever)
Do you have a good name in mind?   I would like FFI in it's name, but not
SharedPool (that's a low level impl detail). I don't want to couple with
"Constants" either as it may help us with other stuff like sizeof() etc.
I guess it should be something related to FFIPreprocessorInfoExtractor or
something like that.

BTW2: Yes, I have my own "OSProcess" working, called OSSubprocess:
https://github.com/marianopeck/OSSubprocess/

Thanks!!

>
>> 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
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>

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