While I am not prepared to engage in a discussion about what "immediate need" is, or is not, I would like to emphasize that the current j implementation does not properly implement 2!:1.
Currently, 2!:1 on a mac behaves exactly like 2!:0 - it waits until the child process completes before it returns. This conflicts with the dictionary definition and so should be considered to be an error. There's also a problem with the implementation of 2!:5 - it returns 0 instead of the environment. As for a cd implementation. Joe Bogner is correct that jtask provides useful implementations - and it might even be that the fork_jtask_ should be considered a model implementation for 2!:1. That said, the naming conventions here are getting a bit confusing. Here's what fork looks like, implemented using cd on a mac: fork=: '/usr/lib/libSystem.B.dylib _fork > i'&cd This is a routine which when called once returns twice. Using this mechanism requires some care as you do not know which copy of J any specific input will be going to. Example use: fork=: '/usr/lib/libSystem.B.dylib fork > i'&cd exit echo fork '' 38371 0 The value 38371 here was a process id, and is the value which is returned in the "parent" or "original" j process. This number identifies the other process (and if you need the process id of the parent, you can get it before calling fork using an expression such as '/usr/lib/libSystem.B.dylib getpid > i'cd ''). Note of course that /usr/lib/libSystem.B.dylib would need to be something different on non-mac systems such as linux. I don't know if anyone has made a cannonical list of libc values for the major platforms where J is supported? Anyways, back to fork... The 0 value is returned in the "child" or "new" process. And when fork is used, this value is what gets used to determine what happens next in each process. But that's the easy part. There's also executing another program. If you use fork_jtask_ you get this automatically, though with a few subtle limitations. But implementing a direct interface to libc's execve stumps me. I *think* this should work, but it does not: execve=: '/usr/lib/libSystem.B.dylib execve > i * * *'&cd execve 'sleep';(<(,'1');0);<'a=b';0 |domain error: cd The second and third arguments to execve are supposed to be a null terminated list of strings, but I'm not quite sure how to make that work. Perhaps I need to explicitly write them all to memory using mema? I can try that when I get a moment to work it through... But another problem is that when execve fails it returns a result in the errno variable, and I don't know how to get its address. (I think I could read from the variable using memr if I had that address.) A possibly related issue is that the third argument to execve is typically a potentially modified version of the null terminated list of strings stored in the environ variable. I don't know how to get that address either (though I can think of some inefficient and/or inaccurate workarounds for that particular case). Anyways... this is a start? But obviously there's more work to be done. Getting at (errno) and maybe even (environ) might be useful. Enumerating values for the libc file would be a definite plus. And, of course, figuring out the right way of calling routines which take null terminated lists of null terminated strings (such as execve) might matter. Do you have any advice along these lines? Or, if I am going to take advantage of the ability to split into two J processes, I would want to come up with a way of getting results back at the end. That probably means files, or sockets. I'd probably need to write some C code to close stdin (in C, that's file handle 0), so that the child doesn't get input meant for the parent. Or, at least, that's how it would have to be for jconsole. For jhs, I guess I would need to close port 65001 or whatever jhs is using. And I have no idea what the analogous operation would be for jqt... Thanks, -- Raul On Mon, Jan 11, 2016 at 1:40 PM, Eric Iverson <[email protected]> wrote: > I agree this (process/task) area is one where J could benefit from new work. > > I am pretty sure that the proper framework could be provided for all > platforms in a portable manner with cd. That is, there is no immediate > need for jsource changes. > > The cd implementation might be adequate, and at worst it would provide > specs for jsource changes.. > > Volunteers?: > > On Mon, Jan 11, 2016 at 1:12 PM, Raul Miller <[email protected]> wrote: >> I was reading >> https://computinged.wordpress.com/2016/01/11/announcing-a-new-framework-to-define-k-12-computer-science-education/ >> and his point about processes struck a nerve. >> >> A process (as opposed to a task*) is a pretty important concept, and >> one that we've been sloppy about, in J. >> >> 2!:1 is documented as returning '' instead of the process id needed >> for 2!:3. It's also documented as not working on windows (even under >> cygwin). I think both of these are mistakes. And on top of that, on a >> mac: >> >> 2!:1 'sleep 3' >> >> does not return immediately. At least, not with >> >> 9!:14'' >> j804/j64/darwin/release/commercial/www.jsoftware.com/2015-12-21 18:06:25 >> >> (Is chat the right forum for non-beta bug reports?) >> >> Thanks, >> >> -- >> 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
