[uClinux-dev] SIGALRM and msgrcv [PATCH]

Robert Daniels robertd at vantagecontrols.com
Mon Nov 25 12:26:13 EST 2002


I think I finally figured out mostly what was causing my problems.  As
it turns out, my application was getting into a state where a SIGALRM
was marked as pending, but the sigpending flag for my process was set to
zero, so my signal handler didn't get called.  After snooping around in
the kernel code for signal stuff, I discovered a slight inconsistency
between m68k/m68knommu and all other architectures when it came to the
architecture specific signal.c file.  I made some comparisons and found
that calls to recalc_sigpending were wrapped in spin_lock_irq calls.  I
made my version of signal.c match more closely the other architectures
and now things work much better.  I'm guessing that at some point, m68k
was forgotten in a bug fix for signals and the m68knommu just carried
that problem forward.  I've included a patch (linux-2.4.x) for the
signal.c found under arch/m68knommu/platform/5307, but it looks like
something similar needs doing for the one under
arch/m68knommu/platform/68328 as well as the one under arch/m68k/kernel,
but I don't have patches for them.  Is this something that needs to be
updated in the main Linux kernel as well?  Please let me know if I'm way
off base on any of this.

Thanks!

Robert

-----Original Message-----
From: uclinux-dev-admin at uclinux.org
[mailto:uclinux-dev-admin at uclinux.org] On Behalf Of Robert Daniels
Sent: Wednesday, November 20, 2002 5:34 PM
To: uclinux-dev at uclinux.org
Subject: RE: [uClinux-dev] SIGALRM and msgrcv

OK, I was a little off on my description of my "problem", I've since
figured out some more, but I'm still wondering what's going on.
Basically, this is what happens:

setitimer() - 10 milliseconds
msgrcv()
SIGIO
setitimer() - clear
(process IO)
setitimer() - 10 milliseconds
msgrcv()

Once I hit this last msgrcv, my process is asleep until either a message
is received or a non-SIGALRM is generated.  I checked the status entry
under the proc file system for my process, and it tells me that there is
a SIGALRM pending for my process, but it never seems to actually get
processed until some other alarm or message happens.  I don't think this
should be happening; I've been assuming that signals won't stay pending
forever.  

What am I doing wrong?
Could a device driver foul things up?
Is this the wrong place for questions like this?

I've been looking through the kernel source for a window of opportunity
for such a thing to happen with no luck.  

Anybody got any ideas?

Thanks for your patience and any help anyone might have.

Robert


-----Original Message-----
From: uclinux-dev-admin at uclinux.org
[mailto:uclinux-dev-admin at uclinux.org] On Behalf Of Robert Daniels
Sent: Tuesday, November 19, 2002 6:00 PM
To: uClinux (uclinux-dev at uclinux.org)
Subject: [uClinux-dev] SIGALRM and msgrcv

        I'm attempting to use SysV IPC message queues and I'd very much
like a timeout on the msgrcv function, so I'm trying to use setitimer to
create an alarm that will go off after my wait time to interrupt the
msgrcv.  Now, my problem occurs when the timeout is very short, such as
10 milliseconds.  I'm still not totally clear on what's going on, but
from what I've been able to observe, occasionally, at about the timeout
time, I receive a message which exits msgrcv before the alarm.  I then
cancel the timer, process the message, then set the timer, and do
another msgrcv.  It appears that during that process, my alarm fires and
is not handled, but gets put into the signals pending mask before
schedule() is called in the sys_msgrcv function.  What I then get is a
sleeping process with a SIGALRM pending.  If I send a signal that I'm
handling, such as SIGIO, then the process wakes up and things are normal
again.  This is also true if a message is received.
        I'm trying to figure out how to avoid this and still have a
msgrcv with a timeout - does anyone have any ideas on this?  I would
have thought that the SIGALRM would get handled at some point
(preferably as close to the specified time as is convenient), but sadly
it doesn't.  Is this supposed to be possible/valid under linux/uClinux? 

System info: 
        uClinux 2.4.x 
        MCF5272 processor on my own board 
        uClibc 0.9.15. 
Thanks for any ideas or helpful hints! 
Robert Daniels 

_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signal.patch
Type: application/octet-stream
Size: 2330 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20021125/4862bb7c/attachment.obj>


More information about the uClinux-dev mailing list