On Wed, Dec 23, 2015 at 7:46 PM, phil@highoctane.be <phil@highoctane.be> wrote:
Pharo follows Smalltalk which uses a global object named Smalltalk which in fact is an instance of SmalltalkImage, confusing if you ask me.
I also have felt that same impedance mismatch in the naming, but I thought the accessors were deliberately moved to the instance side to help (maybe later) to minimise global state. So I am guessing that adding class-side accessors is a step backwards - but maybe System class could provide a singleton instance of itself. cheers -ben
I would add a simple class named System which have class-side accessors for static global things like
image => links to the old Smalltalk stdin stdout session environment for ENV vars workingDirectory accessing the process working directory $PWD 'pid'
That's a very easy thing to do, but IMO it will help anybody coming from outside smalltalk to easily find these things. Probably there are more things that would fit here.
I'd like to have that.
The discussion involved Camillo who was very into these topics. His Pinocchio work seemed to have contributions that can be useful of the CLI support for Pharo.
Phil
and just btw, mildly interesting is using sockets rather than pipes for interprocess communication [l]
[j] http://stackoverflow.com/questions/3884103/can-popen-make-bidirectional-pipe... [k] http://stackoverflow.com/questions/6743771/popen-alternative [l] http://stackoverflow.com/questions/25161377/open-a-cmd-program-with-full-fun...
Thanks. I will check that on a second step ;)
2) We believe that there is a large number of OSProcess users that use OSProcess only for executing OS commands AND popen() approach would be more than enough (we will do a survey about this). So, a very simply solution via FFI for these users rather than having all OSProcess, Command Shell, the plugins etc, may be worth.
What do you think?
Now, given some of the difficulties seen when dealing with external processes, I'd be wary of the "async" side of things. Random failures seemingly linked to signal loss are certainly not something I'd like to debug.
Indeed, it won't be easy I guess. But sometimes the process you execute may take quite some time and blocking the VM for that period is not a good choice. So... what would you prefer to solve that? Do you prefer image-based pooling as OSProcess does when IOPlugin is not used?
How much might your work overlap with the Threaded FFI project for Cog?... ..."The Cog VM is single-threaded, providing green threads to the Smalltalk level, as do most Smalltalk VMs. There is a prototype subclass of the CoInterpreter, CoInterpreterMT, which provides a Python-like multi-threaded VM where any number of threads can share the VM with only one running the VM at any one time. This uses an extremely simple low-level scheme for releasing and re-acquiring ownership of the VM designed by David Simmons. This results in any and all FFI calls being non-blocking since there is such a low overhead to making a non-blocking FFI call that all FFI calls can be non-blocking. Eliot has worked on this, implementing the prototype and the reentrant FFI plugin it requires. But this needs to be revived. It would be a really powerful enhancement."
Well, Eliot said I may need to give a hand to them in order to finish the Threaded FFI. However, I am still not 100% certain if the threaded FFI calls to read from pipes would be worth. Eliot said that yes. Anyway, once I have the first version working I will digest this and goes to the next level and see how I can make things better than polling, if polling proves to be a problem.
cheers -ben
P.S. Just another article warning against mixing fork and multiple-threads (which it seems posix_spawn may avoid)...
http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-usin...
Thanks for the reference.
Cheers,
-- Mariano http://marianopeck.wordpress.com