On 21 November 2012 04:53, Max Leske <[email protected]> wrote: > > On 21.11.2012, at 08:47, Igor Stasenko <[email protected]> wrote: > >> 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. > > Initially I thought of system() but I wanted feed the stdout and stderr > streams back into the image. > right. Having a way to communicate with child process is a must.
>> >> 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.. > > I'll try to answer that :) Good. You can count on my help :) > >> >> 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. >> > > -- Best regards, Igor Stasenko.
