Hi Mariano, 2018-05-23 19:57 GMT+02:00 Mariano Martinez Peck <marianop...@gmail.com>: > > > On Wed, May 23, 2018 at 2:46 PM Sean P. DeNigris <s...@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
