I've just noticed that if IFUNIX then share_jmf_ calls map_jmf_ to do the job. But if IFUNIX=0 then the code for share and map are different. Quite likely it won't work as it stands under Windows. The workaround is for mapex to check the value of CLIENT and use map_jmf_ if CLIENT=0, else share_jmf_ .
On Sun, Jan 8, 2012 at 7:17 AM, bill lam <bbill....@gmail.com> wrote: > Ian, > > I have not study the source carefully, but at the first glance, it seemed > that two running J processes accessing the same mapped file. Why > share_jmf_ was not needed? Please correct me if I missed anything. > > Вск, 08 Янв 2012, Ian Clark писал(а): >> This is my eventual solution to the "are you alive?" problem: >> >> http://www.jsoftware.com/jwiki/Scripts/AliveDemo >> >> It doesn't use sockets, but a couple of mapped files instead. The >> (identically coded) processes use them to play pat-a-cake. >> >> For demo simplicity I've coded a 'hard' duty cycle (a while.-loop.) >> rather than one I find much more convenient: a "soft" duty cycle that >> posts an event calling itself again after a given interval. >> >> A "soft" duty cycle has a lot of advantages. You have to play with the >> alternatives to appreciate them, but the main ones are that it dies >> gracefully if there's a code error, and it doesn't lock the session >> window and any UI which the duty cycle happens to be managing. Indeed >> the duty cycle runs in the background, keeping all displays up-to-date >> and leaving you (almost) full use of J facilities. >> >> I'll place a "soft" duty cycle code sample on the wiki in a day or two. >> >> On Mon, Jan 2, 2012 at 6:51 PM, Ian Clark <earthspo...@gmail.com> wrote: >> > Please forgive these questions I post to the list to which I know the >> > answer. Or rather: *an* answer. I learn a lot from others' responses. >> > Even if it's "my way is best after all" -- that's a valuable thing to >> > know. >> > >> > I have two separate J processes running (assume Linux / Darwin, though >> > I'm keen on cross-platform solutions). They communicate by each >> > writing a text file which is read by the other >> > (keep-it-simple-stupid). Is there a neat, robust way of one process >> > asking the other: "are you there?" or "are you still alive?" >> > >> > I'm au-fait with how the yellow-J works, all the solutions involving >> > timer-driven duty-cycles, timeouts, and reading files written by the >> > sister process, Or the files' timestamps, or permissions. But these >> > all seem so clunky. I guess what I want is something that was so easy >> > in the 1970s but is so awkward on today's machines: just reserve a >> > pair of bits in absolute memory -- or a pair of pixels on the screen >> > -- or some inessential system flags -- and play pat-a-cake with them. >> > >> > Once upon a time there was such a thing as "common memory". >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > > -- > regards, > ==================================================== > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
