Thanks, Bill. I look forward to seeing what usleep will do. In fact my existing "polling loop" in J6 is nice and docile, doesn't hang J, and I'm quite pleased with it. It uses 11!:0'timer...' which unlike 6!:3 can measure out fractions of a second, even on the Mac. Of course, 11!:0 is not there in J7...
I guess the polling loop is no real problem. I'm just prejudiced against timers: there are always gotchas, often not appearing until the latest stages of a project. On Tue, Jan 3, 2012 at 1:56 AM, bill lam <bbill....@gmail.com> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
