Dennis Lee Bieber <wlfr...@ix.netcom.com> writes: > On Sun, 15 Aug 2021 00:15:58 -0300, Hope Rouselle <hrouse...@jevedi.com> > declaimed the following: > > Giganews seems to have just vomited up three days worth of traffic... > >>Dennis Lee Bieber <wlfr...@ix.netcom.com> writes: >> >>> >>> Granted, the fact that the Amiga used a shared common address space for >>> all running applications made IPC quite easy -- one looked up the >>> application message port, then added a small packet to the linked list >>> associated with the port. That small packet basically held the address of >>> the message port for returning data, and the address of the data being >>> passed. The closet thing I've seen to that capability on systems with >>> process-isolated virtual memory is (Open)VMS "mailbox" structures. The >>> difference being that the entire data had to be written (QIO) to the >>> mailbox, and the receiver had to read (another QIO call) the message -- >>> this allowed the address space to change. >>> >>> I've not seen anything equivalent in my light perusal of the Win32 API >>> (the various guide books aren't layed out in any way to be a reference), >>> and Linux seems to use UNIX sockets for IPC... No way to search for a >>> connection point by name... >> >>I don't know anything about Amiga, REXX et cetera, so I might be totall >>off here. But since you spoke of your perusal of the Win32 API, let me >>add a tiny bit. I gave myself a quick tour through the Win32 API using >>Pavel Yosifovich's book ``Windows 10 System Programming''. It's a two >>volume work. The thing that impressed me the most was the many ways to >>do the IPC. The purpose the work is clearly to show what is available >>and it it probably does the job well. (I ignored Windows for most of my >>life and now I decided to take a look at it. I don't feel it has much >>of the elegance of UNIX. It's what it is.) > > For a book that was published only a year ago -- it seems to be hard to > find... Amazon has v1, but not v2.
Indeed. I believe it's because it's not quite released yet. I had found it here: https://leanpub.com/windows10systemprogrammingpart2 And this seems to be a sort-of-early-release. I'm not really sure. > I have the "Windows Internals 6th" both volumes. > > The closet those get to IPC is something called ALPC -- and that is > declared to be internal only, not available to third party programmers. > > "Programming Windows 6th" is focused on using C# (which, for the most > part, means using the "managed" API, not the Win32 API directly). Makes sense. > "Mailslots" (I'm using Google to find Windows IPC options) initially > sound close to Amiga message ports... Except there is no status return > inherent to the system; Amiga messages contain a return address so a > program can wait for the status of processing by the destination address. > They also don't qualify as VMS mailboxes as there can only be one reader > (the creator of the mailslot). VMS mailboxes allow multiple writers and/or > multiple readers. > > "File mapping" doesn't provide any form of queuing -- multiple > "writers" would require manually implementing some protocol to track "next > available space" in the mapped file. It would allow bidirectional message > passing, but again that requires some rather nasty overhead information > (when is the return status valid -- it is presumed the client wanting the > return status would get it from the same memory space as the message it > sent, and that space can't be reused until the client explicitly frees it > -- again by some overhead protocol changing headers of free space. > > "Data Copy" also sounds close to Amiga message ports (closer than > "Mailslots"), but the online documentation doesn't indicate if it queues > messages. The documentation doesn't illustrate HOW to return TRUE or FALSE > (processed/rejected). It advices that the receiver should treat the data as > read-only -- though I have to wonder if it /could/ write a return status > into the same message structure before "returning TRUE". > > Named Pipes and Sockets both have the "tied to endpoints" problem, and > in the case of Pipes, may only allow one sender to connect at a time > (sockets are also one connection, but normally the receivers spawns a > thread for each active connection and the connections are made using > different allocated sockets). Thanks for these summaries! -- https://mail.python.org/mailman/listinfo/python-list