[Moose-dev] Re: Can't load OSSubprocess

On Fri, Apr 29, 2016 at 10:22 AM, Thierry Goubier &lt;thierry.goubier(a)gmail.com > > > 2016-04-29 15:17 GMT+02:00 Peter Uhnák &lt;i.uhnak(a)gmail.com&gt;om>: > >> >> >> On Fri, Apr 29, 2016 at 3:08 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com>> >>> >>> >>> On Fri, Apr 29, 2016 at 8:42 AM, Peter Uhnák &lt;i.uhnak(a)gmail.com>>> >>>> I am also interested in this, as I will likely need it next week. >>>> >>>> However if I remember correctly Mariano mentioned that you can't have >>>> OSProcess and OSSubprocess installed at once, and in Moose OSProcess is >>>> already installed; so even if you manage to install it there may be yet >>>> another problem waiting. >>>> >>> >>> >>> That's exactly the reason. I just grab a Moose 6 image to reproduce the >>> problem, and indeed it's that. OSProcess comes already in Moose and both >>> cannot easily co-exist. It's not OSProcess fault, but MINE. This is because >>> for OSSubprocess I am re-using the primitives of OSProcess to capture >>> signals (SIGCHLD for example) and signal a semaphore. So... we cannot have >>> 2 semaphores waiting on a signal. >>> >>> Once I tried a workaround to "disable" OSProcess signaling, but it was >>> not easy. The easiest path would be to have a condition or group or >>> something in Moose Metacello configuration that would allow either loading >>> OSProcess or OSSubprocess. Could this be possible? >>> >>> >> >> We still have a problem that there are many tools that use OSProcess so >> one can still break it accidentally by loading a project. >> >> As for the side-by-side existence, would it be technically possible to >> have a wrapper that would decide whether to give the control to OSProcess >> or OSSubprocess based on who created the process? That way only the wrapper >> would be waiting for the signals. >> > > I also believe that, depending on the project, having code that either > targets OSProcess or OSSubprocess could be done; for example it would be > easy to do this on GitFileTree. A bit harder would be to have a > configuration or baseline which only loads say OSSubprocess if OSProcess > isn't already present on the target image (or the reverse). > > Well... I think there could be an easy way, but that may involve either hacks/overrides or code change in OSProcess. OSProcess tries to re-register it's child process in a couple of places. So... trying to stop doing that will be more complicated. I think the easiest path is to: 1) Let OSProcess to be the one that defines the semaphore and waits for signals 2) Allow OSSubprocess to be tell to stop it's own child watcher (a method to be called explicitly by a user when OSProcess is in the image) 3) Modify OSProcess #grimReaperProcess to throw a notification / announcement when the semaphore is signaled (just before the "self changed: #childProcessStatus"). 4) Define an announcement / notification handler for OSSubprocess that when such a notification is receives, it sends the #updateActiveChildrenAndNotifyDead. What do you think? > Thierry > > >> >> Peter >> >> >> >>> >>>> Peter >>>> >>>> On Fri, Apr 29, 2016 at 1:12 PM, Anne Etien &lt;anne.etien(a)univ-lille1.fr&gt; >>>>>>> >>>>> (From Olivier Auverlot, that is not yet accepted in the list, (I will >>>>> transfer to him until he is on the list)) >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I need to use OSSubprocess in a project with Moose 6. I just tried to >>>>> load it in a new Moose 6 image but that's doesn't work. By the way, >>>>> OSSubprocess works fine in the latest Pharo 5 image. >>>>> >>>>> Please find below the lats lines of Pharo error log: >>>>> >>>>> VM: Mac OS - intel - 1092 - CoInterpreter VMMaker.oscog-eem.1726 uuid: >>>>> 6a968923-b541-4573-bc4f-64fb95e6462d Mar 15 2016 >>>>> StackToRegisterMappingCogit VMMaker.oscog-eem.1726 uuid: >>>>> 6a968923-b541-4573-bc4f-64fb95e6462d Mar 15 2016 >>>>> https://github.com/pharo-project/pharo-vm.git Commit: >>>>> 2b53ae43e6a030759fbfa6ce8737a7f55ba76dd1 Date: 2016-03-15 19:05:06 +0100 >>>>> By: Esteban Lorenzano estebanlm(a)gmail.com Jenkins build #576 >>>>> <https://github.com/moosetechnology/Moose/issues/576> >>>>> >>>>> Image: Pharo5.0 [Latest update: #50732] >>>>> >>>>> UndefinedObject(Object)>>doesNotUnderstand: #waitTimeoutMSecs: >>>>> Receiver: nil >>>>> Arguments and temporary variables: >>>>> aMessage: waitTimeoutMSecs: 1000 >>>>> exception: MessageNotUnderstood: receiver of "waitTimeoutMSecs:" is nil >>>>> resumeValue: nil >>>>> Receiver's instance variables: >>>>> nil >>>>> >>>>> By the way, OSSubprocess works fine in the latest Pharo 5 image. >>>>> >>>>> Someone has an idea ? >>>>> Olivier >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)list.inf.unibe.ch >>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)list.inf.unibe.ch >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- Mariano http://marianopeck.wordpress.com