Ok, thanks Igor.
So it seems the only remaining option (apart from providing a C library) it to
use Assembly. Assembly is not my territory at all but here's how I think it
could work:
…
emitCall: [:gen | | fork dup2 execv |
fork := NativeBoost forCurrentPlatform getGlobalSymbolPointer:
'fork'.
dup2 := NativeBoost forCurrentPlatform getGlobalSymbolPointer:
'dup2'.
execv := NativeBoost forCurrentPlatform getGlobalSymbolPointer
gen asm mov: fork asUImm32 to: gen asm EAX.
gen asm call: gen asm EAX.
"somehow get the fork return value and test for 0.
only execute the following lines if pid = 0"
gen asm mov: dup2 asUImm32 to: gen asm EAX.
gen asm call: gen asm EAX.
gen asm mov: execv asUImm32 to: gen asm EAX.
gen call: gen asm EAX.
]
As you can see, I have absolutely no clue what I'm doing :) (just a good
copycat). I figure that everything from fork() to exec() needs to be in the
same Assembly sequence to ensure that the child process doesn't try to execute
VM code (multiple #emitCall:'s probably wouldn't work).
I think that if you could help me fill in the code for where I simply used a
comment, I could come up with the rest (writing function specs etc.). I'l try
at least.
Cheers,
Max
On 23.11.2012, at 17:00, Igor Stasenko <[email protected]> wrote:
> so here's the answer:
> - no you cannot use FFI for fork/exec..
> because there's too much involved.
>
> Ideally VM should have support for it, because i think even OSProcess
> lacking important bits, like:
> - closing all file descriptors (and in unix fd is not just files, but
> for sockets as well)
> - cleaning/preparing environment before doing exec
> - god knows what else.
>
> now if we take into account that different parts (sockets/files) in VM
> responsible for them,
> and need coordination to do a safe cleanup after fork.. i don't think
> it will be possible to do that using FFI.
> just too much management.
>
>
> --
> Best regards,
> Igor Stasenko.
>
