IBM defined in their OS wait and post SVCs (SuperVisor Calls). This was done in the 1960s or earlier. They were clearly defined for communication between processes and services and integral to the system. Essentially it is the responsibility of a service or whatever to notify via post the requester to satisfy the requester's wait. This service has been essentially unchanged from the users' viewpoint to this day.
Windows and UNIX have been coming up with a number of messaging services as addons to do what these two SVCs do. That's the difference between defining the service as an integral part of the system and adding it later and it doesn't fit well. On Sat, Apr 30, 2011 at 3:20 AM, Ian Clark <[email protected]> wrote: > Thanks Bill. I can see: /Applications/j602/system/classes/socket/ > which contains jserver and jtelnet. > > Thanks, too, to the whole List. I guess I now have an armoury of > techniques to play with. Except the one I was really hoping for -- but > it's reassuring to know from the assembled expertise that it's not > there and I won't be wasting my time by persisting in ignorance of it. > > A nd if I end up suborning a pixel in the screen-buffer I'll be too > ashamed to tell anyone. :) > > I'm coming to the realisation that my antipathy to shared memory, > handshake protocols and faceless asynchronous processes polling data > streams in tight loops is based on past bad product development > experiences and I ought to re-examine my prejudices. Architectures and > processor speeds have come on a lot in the 35 years since we all > thought APLSV was frightfully clever, and there's been a lot of smart > guys slaving away to make these things work. > > But why-oh-why weren't hardware architectures made completely > event-driven in the first place? I respectfully submit that after a > lifetime I find no evidence for Intelligent Design in the evolution of > computer systems. > > > On Sat, Apr 30, 2011 at 4:12 AM, bill lam <[email protected]> wrote: > > Using passing data between mapped file and socket depends on some > factors. > > If processes are running in different machines, it is out of question. > > Communication using tcp socket is slow even running in the same machine > > because the overhead of hand shaking for each data packet. There was once > a > > J Engine Protocol (JEP) in J5 or J6 using socket. Please search for the > file > > jserver.ijs and its companion. > > > > > > Сбт, 30 Апр 2011, Ian Clark писал(а): > >> Thanks, Henry. Reassuring. > >> > >> The Sockets Lab is straightforward enough, and looks to be portable. I > >> can see how to use it immediately to rig-up the elementary > >> control-line I have in mind (at this stage). When I outgrow it I'll > >> remember your wiki page. > >> > >> > >> On Sat, Apr 30, 2011 at 3:26 AM, Henry Rich <[email protected]> > wrote: > >> > Heavens, yes! Sockets are a great way to do interprocess > communication. > >> > Your program works whether the other process is on your machine or on > >> > another. The mechanisms are robust. > >> > > >> > One process listens, the other connects, and from then on you have > >> > symmetric data transfer. Easy as pie. > >> > > >> > I have a socket library on my Wiki page, but it's gross overkill for > >> > what you want to do. Just look up sdsocket, sdbind, sdlisten, > >> > sdconnect, etc. > >> > > >> > Henry Rich > >> > > >> > On 4/29/2011 10:19 PM, Ian Clark wrote: > >> >> Sorry needs to run on Mac or Unix as well. > >> >> > >> >> If I were doing it on Win I'd find a way of using ActiveX, because > I'm > >> >> familiar with that. But I'm new to Mac programming -- at least > >> >> post-1992 Macs. > >> >> > >> >> Interestingly Xcode, the Mac development system, has a > getting-started > >> >> tutorial that emphasises sockets. They are pushing it as the method > of > >> >> choice for inter-process communication. > >> >> > >> >> > >> >> On Sat, Apr 30, 2011 at 2:53 AM, bill lam<[email protected]> > wrote: > >> >>> I guess this is os specific. You may try CreateEvent window api to > create a > >> >>> mutex, and poll for it using WaitForSingleObject api. Of course the > client > >> >>> also needs to co-operate. > >> >>> > >> >>> Сбт, 30 Апр 2011, Ian Clark писал(а): > >> >>>> Suppose I have two J tasks A and B sharing a mapped file F. How can > B > >> >>>> best get to know that A has just changed F? > >> >>>> > >> >>>> AFAICS, B needs to execute a duty-cycle inspecting the directory > >> >>>> timestamp of F using 1!:0 (which may delay for up to a second), or > >> >>>> alternatively watch for a checksum to change on F's contents (if > it's > >> >>>> large). > >> >>>> > >> >>>> Before I do, is there some JAL facility I've overlooked? Ideally, > the > >> >>>> very act of A changing F should send a message to B -- a system > event, > >> >>>> say, that can run a callback. > >> >>>> > ---------------------------------------------------------------------- > >> >>>> 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 > >> > ---------------------------------------------------------------------- > >> > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
