[Vm-dev] Have anyone thought of binding Spawning Processes from Gnome glib?

[Mariano Martinez Peck]

Hi guys,

I was carefully reading the thread " Can OSProcess functionality be
implemented using FFI instead of plugin?" [1] and I wanted to say:

I started a prototype to wrap posix_spawn family of functions from FFI. And
while it works, you soon start having the problems you mentioned in that
thread regarding missing macros, ifdef hell, missing constants, and
everything that the pre-processor does and so it complicates making some
function calls.

At the same time, I made a survey about forking process and it seems
Windows is still quite used.

I know Levente wrote a ProcessWrapper which is a VM plugin for the Windows
API CreateProcess. And OSProcess implements everything needed for fork() +
exec().

However, I am trying to get something working via FFI if possible (at least
most of it) and if possible to try to *not* manage all the windows / unix
differences myself.

At the very end of the discussion [1] Nick Ager said:

* "Perhaps *a* way forward is to try to find existing projects which have
already created cross-platform abstractions for platform specific
functionality. Then we can use FFI to access that interface in a similar
way to OpenGL and OpenDBX. For example NodeJs works across unixes - perhaps
they have a useful cross-platform abstraction, boost  has abstractions of
IPC etc *
*"*

And so, I come up with Gnome glib functions for spawing processes [2]. The
API seem to have everything we normally would need, and it manages
internally the differences between Unix / Windows. In Unix it will rely
internally  in fork() + exec() while in Windows it will use ProcessWrapper.

So I was thinking if it would be wise to wrap that functions via FFI. They
also have some constants, macros, etc. But since it is only one (and not
one per platform), I can easily read the values from header files.

Of course there are advantages. Advantages I see:

1) We do not have to deal with Unix / Windows differences ourself
2) We can call it from FFI because we do not have to deal with
pre-processor issues across multiple OS
3) Gnome glib seems to be alive
4) We do not have to reinvent the wheel

Disadvantages:

1) We depend on a third party lib
2) We need an extra lib
3) We probably (if I can develop such a tool and it's well received) should
ship the VM with glib compiled ??  that means compiling it as part of our
vm building as external lib (same way Pharo does with Cairo, libgit2,
freetype, etc...) .. this is a pain..
4) Maybe we are getting into a bigger problem....

So guys, do you have any insight?


[1]
http://forum.world.st/Can-OSProcess-functionality-be-implemented-using-FFI-instead-of-plugin-td4610297.html
[2] https://developer.gnome.org/glib/stable/glib-Spawning-Processes.html

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160104/9d5950ac/attachment-0001.htm