some problems for an introductory python test

[Hope Rouselle]

Dennis Lee Bieber <wlfraed at ix.netcom.com> writes:

> On Sun, 15 Aug 2021 00:15:58 -0300, Hope Rouselle <hrouselle at jevedi.com>
> declaimed the following:
>
> 	Giganews seems to have just vomited up three days worth of traffic...
>
>>Dennis Lee Bieber <wlfraed at 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!