Re: Protected hash map (efficient programming with a protected type)

[Victor Porton <porton@narod.ru>]

Randy Brukardt wrote:

> "Victor Porton" <porton@narod.ru> 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