[Pharo-project] Fwd: [ANN] Limbo: a simple shell wrapper for NativeBoost
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 <lewis@mail.msen.com> 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.
On 21.11.2012, at 08:47, Igor Stasenko <siguctua@gmail.com> 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.
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 :)
On 20 November 2012 17:56, David T. Lewis <lewis@mail.msen.com> 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.
On 21 November 2012 04:53, Max Leske <maxleske@gmail.com> wrote:
On 21.11.2012, at 08:47, Igor Stasenko <siguctua@gmail.com> 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 <lewis@mail.msen.com> 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.
participants (2)
-
Igor Stasenko -
Max Leske