[Pharo-project] [Vm-dev] Re: Can OSProcess functionality be implemented using FFI instead of plugin?

[Mariano Martinez Peck]

On Sun, Jan 17, 2016 at 12:28 PM, Levente Uzonyi <leves at caesar.elte.hu>
wrote:

>
> On Sat, 16 Jan 2016, Mariano Martinez Peck wrote:
>
> (Again no quote.)
>
> My question was obviously unrelated to the plugin with the constants.
> I was just wondering if there's a reason to use FFI instead of OSProcess.
>

Well, the discussion of FFI vs Plugin, is what Git vs MC is in Pharo
mailing list. It has been discussed a million times and both approaches
have pros and cons. If you want, Google a bit, but I won't loose my energy
yet again in such discussion.


> Based on your answers, I assume that
> - Your solution is Unix/Mac only, since dup and dup2 don't work on
> Windows. At least they didn't work when I wrote the ProcessWrapper plugin.
>

Yes, and this has nothing to do wether it is FFI or plugin. OSProcess dose
use dup2 too.


> - You have the drawbacks of non-blocking streams: polling, repeated write
> attempts.
>

Yes, but it even seems it's not a big deal for most users having
non-blocking streams with image-based polling. This is confirmed but the
survey I made weeks ago (40 answers so far). In any case, thanks to Eliot,
Esteban, and many others, we are hoping to have threaded FFI callout soon.
So that will allow blocking threaded callouts. And I wonder...wouldn't be
even easier this with FFI rather than plugin? Once the threaded FFI
callouts are done, then I have nothing special to do. Contrary, OSProcess
plugin should understand and know how to mange the threads I imagine for
that, right?


> - You have to solve the problem of different platforms (constant values,
> library names and paths, etc), something that OSProcess handles by default.
>
>
Sure, and that was the whole point of my answer to Eliot proposal. But you
are missing something. If we can make such a solution, that would be
general, for every possible FFI tool. NOT ONLY for my OSProcess
alternative.



> All this makes me wonder:
> - Why do you want this FFI-based solution at all? - How will it be better
> than OSProcess?
>

Already answered.


> - If you decide to make a plugin as well to tackle some of the problems,
> why make it a mixed solution instead of plugin-only?
>
>
If we can make this tool for the constants, the only thing I would need
from a custom plugin or OSProcess is the custom handler (semaphore) to
receive signals. And that's only if you want to catch SIGCHLD in order to
collect exit status. If the user chooses to do a polling wait, then that's
not even necessary.



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160117/92df2f85/attachment.htm