Hi Mariano,

2016-06-07 16:04 GMT+02:00 Mariano Martinez Peck <marianopeck@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.uhnak@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.uhnak@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




--