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