Newsgroups: comp.parallel.pvm
From: dubnicki@blizzard.princeton.edu (Cezary Dubnicki)
Subject: Re: Once more: Signals & PVM
Organization: Princeton University
Date: Tue, 21 Feb 1995 16:53:26 GMT
Message-ID: <1995Feb21.165326.764@Princeton.EDU>

crispin@helix.cse.ogi.edu (Crispin Cowan) writes:

>In article <3hvop8INN8bq@duncan.cs.utk.edu>,
>Philip Papadopoulos <papadopo@cs.utk.edu> wrote:
>>There are some not-very-elegant ways to circumvent the fact the PVM
>>is not re-entrant.  The most straight-forward method is to
>>block the signal before calling
>>each PVM routine and enable afterwards. If a single X signal arrives while
>>blocked, the handler will be called after it is enabled. If multiple

>Unfortunately, that is not the case.  If a single X signal arrives
>while blocked, it is dropped on the floor and ignored.  UNIX signals
>are stupider than processor interrupts:  they don't persist just
>because they are masked.

Well, "UNIX signals" can mean many different things,
but if we agree on POSIX.1 standard, then Philip Papadopoulos
is right: signals cannot be completely lost while they are blocked;
at least one has to be delivered after they are unblocked.

That is, if signal X is blocked and many instances of X arrive 
in the meantime, at least one X has to be delivered when 
it is unblocked (the other occurences of X can be lost though).
For more info consult Stevens "Advanced Programming
in the UNIX Environment"

I have written a PVM based library which receives
messages in signal handler (i.e. a signal is sent after each
pvm send, and there is no explicit receive operation).
Signals are blocked each time PVM function is called in the main
thread of execution.  I use  sigaction and sigprocmask POSIX calls.
So far it works on LINUX, OSF/1 and ULTRIX.

Cezary

----------------------------------------------
Cezary Dubnicki
Computer Science Department
Princeton University




