Ah, ok , so its even better than i thought. Indeed , if purpose of Limbo is to provide an interface to exec(ve) system functions, then there's no need to care a lot about VM state after fork() call..
Also, Max, did you considered of using system() call? It is much easier.. The downside that it doesn't allows you to control input/output channels of running child process, of course. Anyways, your project can give a definitive answer to a question, which i asked some time ago: - can OSProcess functionality be implemented via FFI or not.. On 20 November 2012 17: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). > > Dave > -- Best regards, Igor Stasenko.
