black@yoyodyne..westford.ccur.com (Sam Black) (10/18/90)
In article <2274@gazette.bcm.tmc.edu> etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) writes: > The X api operates using the network services calls. Any X program > will make these calls. Not true. Only some implementations use the network service calls. An efficient implementation might have bypass methods if the client and server are on the same machine (depending on the machine and O/S architecture). The network service calls in "acm" appear to provide the client access to the acm server, not the X server. - sam ------------------------------------------------------------------------------- Once you remove the absurdity from human existence, there isn't much left. __________ / _______/__ ...!{decvax,uunet}!masscomp!black /__/______/ / black@westford.ccur.com Concurrent /_________/ Computer Corporation -------------------------------------------------------------------------------
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (10/19/90)
In article <61273@masscomp.ccur.com>, black@yoyodyne..westford.ccur.com (Sam Black) writes: |> In article <2274@gazette.bcm.tmc.edu> etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) writes: |> > The X api operates using the network services calls. Any X program |> > will make these calls. |> |> Not true. Only some implementations use the network service calls. An |> efficient implementation might have bypass methods if the client and server |> are on the same machine (depending on the machine and O/S architecture). |> The network service calls in "acm" appear to provide the client access to |> the acm server, not the X server. |> |> - sam |> I was under the impression that the network services were "smart" enough to figure out that you were talking to your own machine and use the cheapest method available for talking bewteen 2 processes on the same machine. If this is indeed the case, why would an X implentation try to bypass this by re-inventing the wheel. -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bmc.tmc.edu (713) 798-3776
mouse@LARRY.MCRCIM.MCGILL.EDU (10/19/90)
>>> The X api operates using the network services calls. Any X program >>> will make these calls. >> Not true. Only some implementations use the network service calls. >> An efficient implementation might have bypass methods if the client >> and server are on the same machine [...]. > I was under the impression that the network services were "smart" > enough to figure out that you were talking to your own machine and > use the cheapest method available for talking bewteen 2 processes on > the same machine. > If this is indeed the case, why would an X implentation try to bypass > this by re-inventing the wheel. Primo: Not all network implementations are that intelligent. (Though nearly so by now, one hopes.) Secundo: The cheapest method available for talking between 2 processes does not necessarily fit the network IPC model well enough for the network code to transparently map the calls. For example, a shared memory segment may be the optimal method, but that doesn't fit the byte-stream model the network calls use, so there's no way for the network implementation to pretend to be a network connection but really give the speed that could be attained by using a shared memory segment (plus perhaps a semaphore or some such for signaling). Tertio: The cheapest method available at the point at which it is noticed that the connection is a loopback is not necessarily the cheapest available. For example, a UNIX domain connection may be faster than a "loopback" Internet domain connection, because the Internet connection has to go through all the TCP code. The semantics are slightly different and the implementation of the Internet domain connection is in no position to decide that the program isn't going to depend on the difference, though in the case of X it isn't. Note that none of the above is *necessarily* true anywhere. However, I feel sure that for each of the above there is somewhere a system for which it is valid, and for some I know of such systems. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu