<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 17, 2016 at 12:28 PM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Sat, 16 Jan 2016, Mariano Martinez Peck wrote:<br>
<br></span>
(Again no quote.)<br>
<br>
My question was obviously unrelated to the plugin with the constants.<br>
I was just wondering if there's a reason to use FFI instead of OSProcess.<br></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Based on your answers, I assume that<br>
- 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.<br></blockquote><div><br></div><div>Yes, and this has nothing to do wether it is FFI or plugin. OSProcess dose use dup2 too. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- You have the drawbacks of non-blocking streams: polling, repeated write attempts.<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- You have to solve the problem of different platforms (constant values, library names and paths, etc), something that OSProcess handles by default.<br>
<br></blockquote><div><br></div><div>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. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
All this makes me wonder:<br>
- Why do you want this FFI-based solution at all? - How will it be better than OSProcess?<br></blockquote><div><br></div><div>Already answered. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- 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?<span class="HOEnZb"><font color="#888888"><br><br></font></span></blockquote><div><br></div><div>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.</div></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br></div>
</div></div>