socket
in [Unix Programming]
|
Prev: IPC based on name pipe FIFO and transaction log file
Next: Learn about proxy sites and how to use them to open blocked sites unlimited downloads from RapidShare and megaupload and increase the speed of the Internet with new sites for free
From: Ersek, Laszlo on 8 Apr 2010 11:08 On Thu, 8 Apr 2010, Rainer Weikusat wrote: > doors are not 'a higher level of abstraction than IPC' because the very > idea behind them is to hide the IPC-part away I'm certainly quoting out of context, but a higher level abstraction is usually there so you can, in exchange for less flexibility, use some feature in a more straightforward way. Sometimes you do not wish to care about all those flexible knobs and switches. Cf. "write()" to a regular file vs. "outsb()" to a disk controller or some such. Trading some expressive power for ease of use is not *indiscriminately* wrong. .... I kind of see my point vindicated by the other thread about meddling, from user code, with the OS' affairs of scheduling and with the CPU's affairs of caching. (No flamebait intended.) lacos
From: Rainer Weikusat on 8 Apr 2010 15:38 "Ersek, Laszlo" <lacos(a)caesar.elte.hu> writes: > On Thu, 8 Apr 2010, Rainer Weikusat wrote: >> doors are not 'a higher level of abstraction than IPC' because the >> very idea behind them is to hide the IPC-part away > > I'm certainly quoting out of context, but a higher level abstraction > is usually there so you can, in exchange for less flexibility, use > some feature in a more straightforward way. If anything, RPC (including LPC) resides at a lower level of abstraction than IPC because it [conceptually] ties parts of the implementations of different processes together: The basic idea is no longer that independently acting entities cooperate by exchanging messages in some abstract format (conforming to some abstract protocol) but that a xPC client process takes control of a xPC server process and forces that to execute a specific procedure/ subroutine (/function): Conceptually, the xPC server is just a subroutine library with a 'weird' interface.
From: Bill Cunningham on 8 Apr 2010 17:12 "Barry Margolin" <barmar(a)alum.mit.edu> wrote in message news:barmar- [snip] > I think there's some mention of them in the book, because they use the > same API, but 90% of it is about network programming. I guess I am going to need PF_INET and AF_INET. the AF is for passing data to struct types members. I am going to have to use pointers and ** and struct types it looks like. But I don't do typedefs, +=, ?: or pointers unless I have too. I'll be having fun when I get the book. -- "Using USENET means you have too much time on your hands."
From: Ian Collins on 8 Apr 2010 19:19
On 04/ 9/10 07:38 AM, Rainer Weikusat wrote: > "Ersek, Laszlo"<lacos(a)caesar.elte.hu> writes: >> On Thu, 8 Apr 2010, Rainer Weikusat wrote: >>> doors are not 'a higher level of abstraction than IPC' because the >>> very idea behind them is to hide the IPC-part away >> >> I'm certainly quoting out of context, but a higher level abstraction >> is usually there so you can, in exchange for less flexibility, use >> some feature in a more straightforward way. > > If anything, RPC (including LPC) resides at a lower level of > abstraction than IPC because it [conceptually] ties parts of the > implementations of different processes together: The basic idea is no > longer that independently acting entities cooperate by exchanging > messages in some abstract format (conforming to some abstract > protocol) but that a xPC client process takes control of a xPC server > process and forces that to execute a specific procedure/ subroutine > (/function): Conceptually, the xPC server is just a subroutine > library with a 'weird' interface. So it's a specialisation, you're right. But it is a higher layer. Can you cite an example where "independently acting entities cooperate by exchanging messages in some abstract format"? All practical IPC involves one process asking another to do some work. There's very little difference between a process that creates a socket then spawns a thread to wait on that socket and a process that creates a door (which spawns a thread which waits on a call). One difference is when creating a door, the kernel manages the threads, which simplifies (and reduces the chance of bugs in) the design. I agree that this specialised, or higher layer approach requires less specialised knowledge to use. But I don't agree that they are only applicable to those who don't understand the fundamentals of IPC. I understand (and used to work in!) machine code, but I choose not to use it. I'm curios where the gulf in communication here originates, which is amusing considering the topic! -- Ian Collins |