The tool could recognize that the J sessions share memory and could use shared files with sockets to synchronize. It could do it transparently, using only sockets when memory is not shared. So the user doesn't have to worry about whether the connection is on the same machine or between different machines.
On Mon, Feb 15, 2010 at 11:25 AM, Dan Bron <[email protected]> wrote: > Well, I am considering this tool in the context of a single (multi-/many- > core) machine. > > We would use sockets for asynchronous signaling (aka verb invocation) and > mapped files for data (aka nouns). This avoids the > unnecessary costs of (de)-serialization. And it's one of the main purposes > of mapped files. > > Starting a new instance of J isn't hard, as we know (A) how we started > (ARGV_z_), (B) our state (4!: for variables in memory, > scripts load), and (C) how to start new processes on this machine > (task.ijs). > > 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). Spreading processes across machines > is the job of a clustering system. > > -Dan > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Don Guinn > Sent: Monday, February 15, 2010 1:11 PM > To: Chat forum > Subject: Re: [Jchat] Multiple cores > > I don't think it would take much to actually move problems once we have > other J sessions available. The socket interface it there. 3!:1 and 3!:2 > provide the tool to transfer the data in a generalized way. Sockets provide > easy notification to coordinate between instances of J. Big problems I see > are security and being able to start J remotely. I don't know where to > start > with them. > > On Mon, Feb 15, 2010 at 11:03 AM, Dan Bron <[email protected]> wrote: > > > Don Guinn wrote: > > > In the meantime, what should we do? We should > > > do as systems like Matlab have done. Supply a > > > toolbox to make it easy to distribute work. > > > > I have considered building such a tool before, and have some ideas for > > high-level architecture. Problem is I don't have the > > appetite to invest all the time in actually building it. > > > > -Dan > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
