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?
Locked
