Raul wrote:
> On Unix (Linux, Mac), C's fork (where the child process is a
I think Perl gets around the differences between Unix' and Windows' definition
of fork by using fork() on Unix and a new thread on
Windows.
But I don't propose the IJC (inter-J-communication) tool actually leverage the
system fork() utility (if that's even possible).
I'm suggesting something along the lines of:
kid =: beget ''
where beget is a conew, and calls something along the lines of:
require 'task'
fork BINPATH_z_, PATHSEP_j_ (, }.~ [ i:~ ,) >{.ARGV_z_
with maybe some extra command line parameters (or stdinput if jconsole) derived
from ARGV or our current state or arguments to beget
(e.g. "Have it define these names, or share them if they're nouns", or "Have it
load these scripts and all their recursive
dependencies").
Then we could do things like:
GLOBALNOUN__kid =: .... NB. Update mapped global noun, so both my
kid & I see the new array
share__kid 'A_NOUN ANOTHER_NOUN THIRD_NOUN' NB. Share more nouns
and furthermore:
exec__kid 'someVerb i.10' NB. Execute in kid
someVerb__kid NB. Cover verb, defined something like someVerb__kid
=: 3 : 'exec ''someVerb '',5!:5<''y'' '
callback__kid =: kidMessageProcessor NB. Handle messages from my kid
to me.
where exec & friends sent messages over a socket established between myself and
my kid, and so the kid could send me message back,
if it wanted. Of course the fact that it's a socket would be abstracted away
(so we could use other mechanisms, when necessary or
where available).
As it evolves, we could add all sorts of neat features, like detecting when a
child is exiting or has died unexpectedly and
automatically cleaning up (e.g. removing filesystem clutter), etc.
-Dan
PS: This IJC processor would be built on top of a more general IJC framework,
which in turn would be built on top of other
frameworks, which could all find independent uses. I've mulled something like
the following diagram:
IJC
^
|
+-------------+----------+
| |
IPC (OOP) J
starter<--cmdln parser
^ ^
| |
+---------------------+-------------------+-------------+
+--+--------------+
| | | | |
|
Socket Server (OOP) Socket Client (OOP) jmf.ijs task.ijs exe start
console start
^ ^ ^
^
| | |
|
+--------------+------+ scriptname
REPL
| |
socket.ijs Timer (OOP)
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Raul Miller
Sent: Monday, February 15, 2010 1:35 PM
To: Chat forum
Subject: Re: [Jchat] Multiple cores
On Mon, Feb 15, 2010 at 1:25 PM, Dan Bron <[email protected]> wrote:
> Using these tools, it wouldn't be too hard to write an equivalent to
> Perl's fork() (where we can have another process "immediately
> pick up where we left off", though of course we spawn unrelated
> J processes if we wanted to).
On Unix (Linux, Mac), C's fork (where the child process is a
clone of the parent process except for one bit that distinguishes
the child and the parent) is faster than C's system (which does
a fork and then executes a new process image).
On Windows, C's system is not faster than on Unix, but
C's fork is much slower than system (because it works
by creating a new process and then copying the entire
memory image from the old process into the new process).
So: fork definitely has some elegance, but its elegance does
not go well with Windows.
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
