From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: Victor Porton Newsgroups: comp.lang.ada Subject: Re: Protected hash map (efficient programming with a protected type) Date: Fri, 17 Nov 2017 02:28:55 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: edFHTOfx8phAphItWrZ8cQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: abuse@aioe.org User-Agent: KNode/4.14.10 X-Notice: Filtered by postfilter v. 0.8.2 Xref: feeder.eternal-september.org comp.lang.ada:48945 Date: 2017-11-17T02:28:55+02:00 List-Id: Randy Brukardt wrote: > "Victor Porton" wrote in message > news:oukt7t$1ifn$1@gioia.aioe.org... >> Process_Descriptor record consists of a process ID (an integer), two file >> descriptors (for stdin and stdout). Process descriptors may also contain >> two >> strings: program input string (formed before the program started) and >> program output string (which is appended every time we get some output >> from >> the program). It may contain more data. > > I'm not sure I understand. In every system that I've ever used, there can > only be one set of process descriptor information for each process ID. > That means the other data is secondary to the process ID, and the ID alone > is sufficient to determine the other information. I store some additional information (such as the retrieved part of its stdout output) in my Process_Descriptor record. To retrieve the additional information about a process with given ID, I need to store the additional information in a map from process ID to Process_Descriptor. So it can be restored from a process ID, but I need to look into a hash map to do it. > Specifically, a running process (with a particular ID) has StdIn and > StdOut file descriptors. But there never are two copies of the same > process (with the same ID) with different StdIn and StdOut information; Certainly, never. > those necessarily have to be different processes with different IDs. > (Perhaps something could change the StdIn or StdOut file descriptors, but > you wouldn't keep the old ones in such a case.) > > Thus, I'd index the map using the process ID (which is typically a small > integer), and use that to retrieve the other information as needed. If the Certainly so. But it amounts to a hash lookup. > process ID is destroyed, one needs a mechanism to remove it (and thus the > other information) from the map. But that can be implemented with just a > normal Delete (assuming the Map is implemented with one of the Ada > Containers). The problem was to do it right in a protected interrupt handler, without breaking atomicity... ... but (see my other post) I decided to do all processing linearized (not in an interrupt), using poll() to watch for all kinds of events, so that I no more need to do it in a protected procedure... in more details: In the signal handler (be it SIGCHLD, SIGTERM, or SIGNINT) I will just send one byte (indicating the kind of the signal) from the task through a pair of pipes to the task itself. Then I will use poll() Unix call to detect when this "one byte" is sent and run whatever I need without the need to make it compatible with signal handlers and without the need to use protected procedures (except of the protected procedure which handles the signal). > Randy. -- Victor Porton - http://portonvictor.org