Following Bill's warning, I've just corrected the downloadable script: alivedemo.ijs at: http://www.jsoftware.com/jwiki/Scripts/AliveDemo The "server" now accesses its jmf file using map_jmf, but the client uses share_jmf_.
Can somebody please verify it works under Windows and tell me? (I don't currently have a windows machine). On Sun, Jan 8, 2012 at 1:06 PM, Ian Clark <earthspo...@gmail.com> wrote: > 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
