Smalltalk › Pharo › Pharo Smalltalk Users
Login  Register

Re: OSProcess command - non responding image when calling often

Posted by Thierry Goubier on Jun 07, 2016; 1:54pm
URL: https://forum.world.st/OSProcess-command-non-responding-image-when-calling-often-tp4899540p4899674.html

Hi Mariano,

2016-06-07 16:04 GMT+02:00 Mariano Martinez Peck <[hidden email]>:
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 <[hidden email]> wrote:
On Tue, Jun 07, 2016 at 01:22:04PM +0200, Thierry Goubier wrote:
> 2016-06-07 11:47 GMT+02:00 Peter Uhnak <[hidden email]>:
>
> > 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




--

Free forum by Nabble Edit this page