Personally, I prefer the version where although the life of the individuals is ephemeral the species survives a lot longer, as it occurs in nature. Either way, looking at the structure of the verb fork_jtask_ and its components, it seems to me that this is a kind of task far more suitable to C than J.
On Wed, Mar 31, 2021 at 10:17 PM Raul Miller <[email protected]> wrote: > Sure, and here's a c program which will run into similar resource limits: > > main() { > while (1) { > fork(); > } > } > > This issue was probably one of the motivations for the ulimit command > (which people almost never use, nowadays, because we have long since > learned to expect distributed programs to be well behaved). > > Take care, > > -- > Raul > > On Wed, Mar 31, 2021 at 6:39 PM Jose Mario Quintana > <[email protected]> wrote: > > > > For some reason, probably the pandemic, recent posts regarding the verb > > fork_jtask_ evoked old memories. In the late '70s, while reading a > passage > > in a book describing Von Newman's scheme for constructing > self-replicating > > machines, I realized I could design a self-replicating process capable of > > running in the computer environment at work. The computer was a > Burroughs > > B6700 and it had enabled the Inter Process Communication (IPC) facility > > which allowed a process to run another process. I wrote a tiny program > and > > showed it as a curiosity to a few of my colleagues telling them that it > > would likely overwhelm the computer; but, for the same reason, I could > not > > test it. > > > > Shortly after I went to work for another institution and, in the early > > '80s, I moved from Mexico to England and I bought a little microcomputer > > called Sinclair QL. It had a multitasking OS called QDOS and a BASIC > > variant called SuperBASIC which was also the QDOS' command-line > > interpreter. So, I rewrote and ran a version of my tiny program and, as > > expected, the only way out was to, literally, pull-the-plug. > > (Incidentally, the machine which looked almost like a keyboard was also > > capable to run QL APL, which was a special version of MicroAPL's > APL.68000.) > > > > I had swamped not only j but also the OS a few times before, but never > > intentionally. So, this is a first for me, the following fleeting > > script (beware of line-wrapping) runs in an earlier custom version of > the j > > interpreter on Windows 10 but it should be able to run in the latest and > > greatest public versions of j and also on other platforms (changing what > > needs to be changed); however, my strong advice, unless one likes to live > > dangerously, is: > > > > DO NOT RUN IT! > > > > NB. Saved as J:/temp/Virus.ijs > > > > (2!:55)@:_:@:(([fork_jtask_)^:2) '"J:/Program Files/J/bin/jqt.exe" > > "J:/temp/Virus.ijs"' > > > > > > PS. Many years later while visiting an old friend in New York, who used > to > > be a member of the staff operating the B6700, he told me that one of the > > most stressful times ever at work was when the B6700 suddenly kept > crashing > > and crashing for a few days, even missing a payroll deadline. The staff > > and the Burroughs technicians could not find anything wrong with the > > hardware. The issue was that the system was too clever, after a crash it > > would automatically restart all the processes which were interrupted. > > Immediately after identifying the culprit, the sneaky tiny program which > > was very familiar to me, the general access to the IPC facility was > > disabled... > > > > Long live the verb fork_jtask_! :) > > ---------------------------------------------------------------------- > > 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
