Hi Mariano,

On Sun, Mar 17, 2019 at 08:29:59PM -0300, Mariano Martinez Peck wrote:
> >
> > ducasse wrote
> > > this is not because we do not care of Pharo that we will fix it
> > > immediately.
> >
> > Yes of course, just want to keep it on the radar (and maybe Mariano will
> > read he he)
> >
> >
> I always do :)

Me too :-)


> But honestly, I don't have enough time to carry on that myself. As you
> could see with latest Guillermo pass, I reviewed every PR and tried to give
> my advice and support as much as possible.

I saw Sean's earlier email (see below) which reminded me of your ideas about
having a child process listener that could provide child exit notifications
to both OSSubprocess and OSProcess. This seems to me to be the right thing
to do, but it would take some work by somebody (not by me, but it could
be done).

Meanwhile, prompted by Sean's <bump>, I think maybe I see another way that
we could handle the problem, at least in the near term.


On Fri, Mar 15, 2019 at 01:42:26PM -0500, Sean P. DeNigris wrote:
> Max Leske wrote
> >> I was talking about OSSubProcess
> > Well, I'm not working with that at the moment ;)
>
> [OT] Just want to bump the problem that OSProcess and OSSubProcess can't
> currently be used in the same image. This is an important problem because
> users can't control which library dependencies use. Mariano hinted at a
> solution. It didn't seem like a ton of work, but it's beyond my
> understanding.
>

I think I see another way that this can be handled for an image that
contains both OSSubprocess and OSProcess. I loaded both into a Pharo 7
image, then added this:

OSSVMProcess>>update: aParameter
        "If subscribed to events from the OSProcess child watcher, the
        changed/update: mechanism will dispatch child exit notification
        here. To subscribe to notification from OSProcess add the singleton
        OSSVMProcess as a dependent of the OSProcess accessor singleton.
        When any child process exits, this method will be called with
        parameter #childProcessStatus"
        
        "OSProcess accessor addDependent: OSSVMProcess vmProcess"

        (aParameter == #childProcessStatus) ifTrue:
                [^ self updateActiveChildrenAndNotifyDead].


I stopped the child watcher in OSSVMProcess (by commenting out the last
two lines in OSSVMProcess>>initialize just to see if this would work),
then added the changed/update: dependency with
  "OSProcess accessor addDependent: OSSVMProcess vmProcess"

After restarting the image, it appears to be working, at least so far
has having both OSP and OSSP handle their child process exits properly
in the same image.

I don't have time to play with this any more right now, but it does
look like it might be a workable approach. It should be possible to
have the initializer for OSSVMProcess use its normal child exit handler,
but hook into the OSP handler instead if that happens to be present
in the image.

Dave 



Reply via email to