[Bug 1630] sigtimedwait not following POSIX spec

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1630

--- Comment #6 from Joel Sherrill <joel.sherrill at oarcorp.com> 2010-07-27 11:37:07 CDT ---
I want to be sure about the second patch to save and restore wait info.  Being
blocked isn't just about the wait info, it is also about the 
thread state, and where it was on a blocking queue.

Are you trying to do more than save the return status?  (In reply to comment
#5)
> (In reply to comment #4)
> > I want to be sure about the second patch to save and restore wait info.  Being
> > blocked isn't just about the wait info, it is also about the 
> > thread state, and where it was on a blocking queue.
> > 
> Basically, sigtimedwait puts the thread into a wait queue, waiting for a
> signal. Now the thread can come out due to 2 reasons, either being timed out,
> or a signal being caught. It expects to know this information when it comes out
> of the queue.
> 
> The problem right now is that, the signal handling function of the signal, may
> put the thread into another wait queue for its own purposes, and hence
> overwrite this information.
> 
> We just need the information as to why the thread came out of the original
> wait, is it EINTR (signal caught) or EAGAIN (time out). If it is EINTR, we need
> some other information too, like the signal number of the signal which was
> caught. All this information is in Thread_Wait_information. So the save and
> restore of that structure.
> 
> > Are you trying to do more than save the return status?
> 
> I am only trying to do that, yes. I don't have much idea about the other things
> like thread state and stuff. Is it a problem if that information is overwritten
> when the thread goes into the new wait queue ?

No.  If all you are doing is saving some return information, this is fine.
I was worried about you wanting to interrupt the thread while it was blocked
on something else.then have it process the signal and think it was going
back into the original wait queue just because of the memcpy. I think this
is correct.

I have committed the code.  Please close this if it looks OK on your side.

FQWIW if this introduced an area of code that is now untested (e.g. no
coverage), I will file another PR for that and assign it to you.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.