On Mon, 5 May 2003, Henrik R. Nagel wrote:
> I have now discovered, that the underlying problem is the use of
> "nanosleep". For some reason, this function, as well as usleep and
> select, disables the signal handlers.
Really? That sounds fishy. I'm quite sure that select() does not disable
signal handlers. I don't know about nanosleep or usleep -- although I
don't know for sure, and I'm assuming that they may [temporarily] hijack
SIGALRM, but I can't imagine that they actually disable all other signals.
Indeed, in the man pages for these functions, I see that they can return
EINTR, inidicating that they were interrupted by signals...?
> I have e.g. one process running a menu, which most of the time is
> waiting for user input. This process must call nanosleep or usleep,
> since it otherwise would be using up all CPU time. The signal handlers
> are therefore disabled, when the process is given the SIGINT signal.
>
> In another process, I have tried to replace a usleep with an MPI_Recv.
> However, this also results in the process using up all CPU time.
FYI -- this depends on where you're receiving from and what RPI device
you're using. The usysv RPI, for example, uses spin locks. So if you do
a receive that will come from the local node, it'll eat CPU until
something is received. The sysv RPI, for example, uses SYS V semaphores,
so if you do a local receive, it should block and not consume too many
cycles.
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
