[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Signal doesn't interrupt read() and wait() - help!


I can't say anything about the problem, but this reminds me something else
about signals. Some software is supplied with autoconfig scripts those do
many strange things ;) before compiling in order to setup the source
appropriately. I noticed that such scripts usually report "not reliable
signals" (e.g. irc 4.4 does that). I am wondering what does this exactly
mean and if it isn't the problem for mgetty/sendfax?

Konrad M.Kokoszkiewicz
mail: draco@mi.com.pl

** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
** U pospolstwa normalne jest, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.

On Wed, 4 Feb 1998, Mario Becroft wrote:

> Hello,
> I've been trying to get mgetty+sendfax and vgetty working under MiNT.
> After kellis pointed out a few things it was mainly problem-free, except
> for one big problem. Unfortunately I'm not very familiar with UNIX
> programming and I can't figure out what exactly is going wrong here.
> In several places, the software uses read() or wait() and remains in the
> call for long periods. During this time, it's possible that a signal might
> be received.
> The signal is being received without a problem, but the read() and wait()
> calls do not return when the signal is received. The software relies on
> these calls returning with EINTR status whenever a signal is received, but
> the calls are just not returning at all.
> So although the signal is being delivered, the software is never
> processing the signal, since it only processes the signal after the read()
> or wait() call does return.
> So what's going on here? As far as I can see, UNIX read() and
> wait() obviously do get interrupted by a signal, since this software
> where the problem shows up is known to work on various UNIX systems. But
> it doesn't work under MiNT, because these calls don't return when a signal
> arrives. Therefore I can only deduce that this is some sort of bug in
> MiNT, but then surely it would have been noticed, and corrected, before.
> So I hope someone who knows about this can clarify the situation for me.