Hi Mariano, 2016-06-07 16:04 GMT+02:00 Mariano Martinez Peck <marianop...@gmail.com>:
> Hi guys, > > I will try to answer many things at once: > > 1) Sabine, OSSubprocess works for Unix derived, not only Linux, that > includes OSX as well. > > 2) Tierry,Sabine for the case of loosing signals, the most trustful > solution (in OSSubprocess) is to rely on a delay pooling instead of on the > child reaper (based on signals). I am talking exactly about this API: > https://github.com/marianopeck/OSSubprocess#delay-based-polling-waiting > Which is what GitFileTree uses. I remember asking you for a similar API :) Polling to avoid the child reaper is also what GitFileTree does on the OSProcess side. > > 3) I found a problem/bug with waits and signals in Pharo 5.0 as reported > here: > https://pharo.fogbugz.com/f/cases/18359/Problem-with-DelayExperimentalSpinScheduler-and-delay. > That should also affect OSProcess. What I did in OSSubprocess v0.2.4 ( > https://github.com/marianopeck/OSSubprocess/tree/v0.2.4) is automatically > set the mentioned workaround in the issue tracker. This may fix your issue. > I understand that. I had a few lock-ups prior to that with GitFileTree and OSSubprocess, even with the polling interface, and I noticed that discussion (and the fact someone else complained of lost signals when connected to a database as well). But I don't know what the status is exactly for each version of the Pharo VM. Thanks, Thierry > > > Hope any of this helps. Let us know. > > Cheers, > > > > > On Tue, Jun 7, 2016 at 10:21 AM, Peter Uhnak <i.uh...@gmail.com> wrote: > >> On Tue, Jun 07, 2016 at 01:22:04PM +0200, Thierry Goubier wrote: >> > 2016-06-07 11:47 GMT+02:00 Peter Uhnak <i.uh...@gmail.com>: >> > >> > > It's strange that I was using GitFileTree over OSProcess for a long >> time >> > > without issue and yet every time I tried to use OSProcess directly I >> had >> > > this locking up. >> > > >> > > >> > Yes. This is a bit worrying; the low-level OSProcess call was a bit of a >> > stopgap while waiting for either OSProcess or the vm to sort the >> underlying >> > issue (which is more significant than just my use); that it locks up >> under >> > normal use is not good and should be reported. >> > >> > I allways considered GitFileTree to be a heavy hitter on OSProcess, >> running >> > hundreds of external commands to load a complex project, so that if I >> would >> > lock up, it wouldn't be a normal pattern of use. >> > >> > >> > > >> > > > So I am asking polite to the pharo developers team if there are >> plans to >> > > > provide a stable solution for calling external programs as >> described. >> > > > >> > > > My production system will be a windows system, so I need this for >> > > windows, >> > > > too. >> > > > As far as I understand, the new OSSubprocess is (currently) only for >> > > unix. >> > > >> > > Yes, there's ProcessWrapper for Windows. >> > > >> > > An alternative approach might be to use direct FFI calls, e.g. >> > > >> > > MyClass class>>system: >> > > system: command >> > > "Perform OS system() call." >> > > >> > > ^ self ffiCall: #(int system #(char * command)) module: LibC >> > > >> > > And then you can do MyClass system: 'cp a.pdf b.pdf'. >> > > >> > > Although it still locks up my image from time to time… but at least >> order >> > > of magnite less. >> > > >> > >> > Than GitFileTree or OSProcess? Still, you get lockups... which isn't >> good. >> >> No, GitFileTree never locked up my image. This was always my use. >> >> Peter >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >
