Even under Windows, I guess sdasync will not work under jconsole. You still need polling. My experience is that it only takes 2 to 3% of cpu time to run a polling loop. A gotcha is the delay (6!:3) has a minimum of 1 second, less than that will be no delay (100% cpu cycle). A new verb usleep has been added to base library and will be available on the next update.
I also add istty and getargs form Joey to base library if that won't be reverted by Chris. Втр, 03 Янв 2012, Ian Clark писал(а): > Thanks, Henry. > > I've just got a lash-up working using a pair of mapped files. But I > shall adapt the socket demo too, and see which serves me best in > practice. > > The first thing that strikes me is that sdasync does not work on my > Mac (though everything else seems to). I see the line: > > if. IFUNIX do. 'not implemented under Unix - please use sdselect' > assert 0 end. > > ...which I take to mean that I'll have to call sdselect'' periodically > to check for data waiting, as I'm doing with the mapped files. This is > no problem for the task in-hand because the listening process is > already running a duty cycle, and I can slot the sdselect in there. > > But it's a pity in general. The big attraction of sockets for me is to > be able to have process A trigger a callback in process B. All the > other techniques I know require process B to opt to look periodically > for incoming data from A and act on it. > > > On Mon, Jan 2, 2012 at 10:01 PM, Henry Rich <henryhr...@nc.rr.com> wrote: > > Sockets seem right to me. > > > > You can use an async socket to get notified when something comes in, > > and immediately reply (immediately as in, next time J goes to immex). > > One process could ping the other that way. Or, they could just send > > heartbeats to each other. > > > > Shared files, or pixels, require that the machines be on the same local > > network or machine. Sockets are completely general. > > > > Henry Rich > > > > On 1/2/2012 2:38 PM, Ian Clark wrote: > >> Thanks, Raul. I'll look again at the sockets solution. > >> > >> Some time since I ran that lab, but I seem to recall it had a timer to > >> poll the link hidden somewhere, so I think I dismissed it from my mind > >> for that reason. IMO it's as clunky as my other solutions: certainly > >> clunkier than the yellow-J approach. One good thing was the ability of > >> one process to send a "message" triggering a callback in the other > >> process. Specifically to execute a given J sentence. That would solve > >> most things. But is it a proper message, placed in the system's event > >> queue, or something the other process has to poll for? > >> > >> A message "are you alive?" sent via a socket would surely need a > >> timeout to register the answer "no"? > >> > >> A pair of mapped files might provide the nearest thing to my > >> recollection of 1970's-style "common memory". In the days before it > >> was deemed vital to build Chinese walls between asynchronous > >> processes. If each process updates a timestamp in its mapped file, > >> then a simple match (-:) would verify the other process is (still) > >> running. You wouldn't even need mapped files: just read the directory > >> timestamps. > >> > >> Both process, I might add, are already having to run their own > >> timer-driven duty-cycles for other purposes. Oh for a system > >> "heartbeat", which could trigger an "Idle" event in any given process! > >> > >> On Mon, Jan 2, 2012 at 6:59 PM, Raul Miller<rauldmil...@gmail.com> wrote: > >>> I think I would use (non-blocking) sockets for this. > >>> > >>> If you are using j6, I'd point you at the socket labs, which > >>> demonstrate their use. I am not sure what state those labs are in for > >>> j7. > >>> > >>> -- > >>> Raul > >>> > >>> On Mon, Jan 2, 2012 at 1: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 > >>> ---------------------------------------------------------------------- > >>> 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 -- 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
