Hi Mariano, hi Thierry, I cannot follow up for a few days but I like Mariano's proposal and I think that it will work. Maybe move the child reaper process to a small OSChildWatcher class and have interested clients (OSP, OSSP, others) subscribe to update notifications. Dave
Hi Thierry. Excellent question. For OSSubprocess this is not an issue because I look up by pid in my list of forked children... So if not found I do nothing... At least that's what I remember (away from my machine now). So at worst it would be a performance problem when both loaded.
As for osprocess I don't recall if this would be a problem but I imagine it won't. Maybe David can tell.
On Wed, May 23, 2018, 5:31 PM Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Mariano,
2018-05-23 19:57 GMT+02:00 Mariano Martinez Peck <marianopeck@gmail.com>:
On Wed, May 23, 2018 at 2:46 PM Sean P. DeNigris
<sean@clipperadams.com>
wrote:
David T. Lewis wrote
FFI based solutions work at a different level of abstraction than VM plugins, and there is a role for both.
Thanks for the context, David. Now that we understand the different niches, the main problem is that they can not be loaded in the same image
without
breaking :/
The problem is to find a solution that works for both, Squeak and Pharo as well as for OSProcess and OSSubprocess.
I guess one possibility is to modify both, OSProcess and OSSubprocess initialization of the child reaper so that they install the same "generic" child reapear. Aside from initializating the child repear, they should be added into an "observer list". When, when it comes the second project to get loaded it which check that a child reaper is already registered..in which case he just register itself as "observer".
This child reaper should be generic enough (cannot be coupled to WHAT to do when the semaphore is signaled). Using Announcements (or other mechanisim that would work for Pharo and Squeak) we could simply "notify" the registered observers and each observer would do whatever is needed (what is actually now hardcoded in each child reaper)
Maybe that works...just an idea.
I think that looks like a nice design. Just one question: do we need to track down whether the child reaper event should be directed to OSProcess or to OSSubprocess? Wondering if there is an issue with one of them trying to close the other one's resource (but I haven't checked, so I may be wrong).
Thierry
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
-- Mariano http://marianopeck.wordpress.com