I have run into a small problem with fork():
pid := self primitiveRun.
pid isZero
ifTrue: [ "child code with exec" ]
ifFalse: [ "parent code" ]
primitiveRun
<primitive: #primitiveNativeCall module: #NativeBoostPlugin>
^ self nbCall: #( int fork() )
Only the parent code is ever executed, #pid is never 0.
Looking at UnixOSProcessPlugin I see that there are some special things Dave
did before forking and I'm wondering if these would be necessary with NB. In
the method #forkAndExecInDirectory:
1. possible use of a sig handler
2. special secure mode handling (what's that?)
3. turn off the interval timer
Any ideas?
Cheers,
Max
On 21.11.2012, at 08:50, Max Leske <[email protected]> wrote:
>
> On 20.11.2012, at 21:56, David T. Lewis <[email protected]> wrote:
>
>> On Mon, Nov 19, 2012 at 05:46:14PM -0300, Igor Stasenko wrote:
>>>
>>> Providing bindings to fork/pipe kernel functions is piece of cake.
>>> But writing a wrapper around it would be a bit of work.. but still it
>>> is possible. And you should try.
>>>
>>> And yes, using fork() stuff having many treacherous pitfalls, but
>>> don't think that if you call this function from code written in C
>>> instead of NB will make it less treacherous.
>>> I think Dave can give some more input on that, because he also using
>>> fork() in OSProcess.
>>
>> In normal use, the fork() call is immediately followed by an exec(), so
>> it is not tricky at all. The only thing that was tricky to do in OSProcess
>> was forkSqueak() which forks the VM itself and then attempts to continue
>> running. But that is really an unusual use case.
>>
>> The system calls such as fork() and pipe() should work the same whether
>> you are calling from FFI or from generated C in a primitive. You can
>> find examples for many of these calls in OSProcess. In general, the
>> interface to system calls and standard C library functions is in
>> UnixOSProcessPlugin, and the associated glue to tie it into the image
>> is in UnixOSProcessAccessor. I have not looked at it closely but I
>> think that in some cases you could change the methods in
>> UnixOSProcessAccessor
>> to make FFI calls, at least in order to get something working initially
>> (I don't know if the design of OSProcess is what you want, but it could
>> get you started).
>>
> Thanks Dave, that's good to know.
>
> Cheers,
> Max
>
>> Dave
>>
>>
>
