[Tcl-bugs] [ tcl-Bugs-3608957 ] Events posted by Tcl_QueueEvent linger in queue

[SourceForge.net <no...@so...>]

Bugs item #3608957, was opened at 2013-03-24 09:15
Message generated for change (Comment added) made by jenglish
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3608957&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 01. Notifier
Group: current: 8.6.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Schelte Bron (sbron)
Assigned to: Kevin B KENNY (kennykb)
Summary: Events posted by Tcl_QueueEvent linger in queue

Initial Comment:
My C library posts an event via Tcl_QueueEvent when the app receives a signal (like SIGHUP). When using the library with a non-threaded tclsh, the event is picked up by the event loop and processed almost immediately. However, with a threaded tclsh nothing happens until some other event occurs. At that time the queued events and the other event are all processed. Is this the intended behavior?

Issue found on OpenSUSE 12.3 (linux 3.7.10) 64-bit.

I have attached the stripped down sources for a library that reproduces the problem. Run the script and send a SIGHUP to the process. Observe that with a non-threaded tclsh the script reports "signal" immediately. With a threaded tclsh the "signal" report comes out just before the "Boo!".


----------------------------------------------------------------------

>Comment By: Joe English (jenglish)
Date: 2013-03-24 18:00

Message:
The idea behind write-to-pipe is: use pipe(2) to get a pair of connected
file descriptors; in the event loop listen on the read end (with select,
poll, kqueue, whatever), and in the signal handler write a single byte
(generally the signal number) to the write end.  That will wake up the
event loop, which can read the pipe to determine which signal was sent.

write(2) is async-signal safe, whereas almost none of the pthread_*
routines are.  That's why this approach is preferred.

> I switched to Tcl_AsyncMark for my library, because apparently
>  that command was specifically designed to handle cases like this 

That may have been the original intent, but since the first thing
Tcl_AsyncMark() does is lock a mutex, it can't be called from a signal
handler either.

> and it seems to work just fine.

"seems" being the operative word here :-)  If a signal ever gets delivered
while Tcl is in the middle of an AsyncInvoke or other critical section, the
process will deadlock.  

Also beware: async handlers are called at very precarious times; the interp
can be in almost any state, you have to be very careful.  (Scheduling a
callback with Tcl_QueueEvent is about the only thing you should do in an
async handler).

----------------------------------------------------------------------

Comment By: Schelte Bron (sbron)
Date: 2013-03-24 14:23

Message:
Thanks for your suggestions Joe, although I don't know what "the
write-to-pipe technique" is in this context.

I switched to Tcl_AsyncMark for my library, because apparently that command
was specifically designed to handle cases like this and it seems to work
just fine.

If the consensus is that the difference in behavior of Tcl_QueueEvent in
threaded and non-threaded builds is not a bug then I don't have objections
to closing this tracker item.


----------------------------------------------------------------------

Comment By: Joe English (jenglish)
Date: 2013-03-24 09:39

Message:
The signal handler in the attached code calls ckalloc() and
Tcl_QueueEvent(), neither of which are async-signal safe.

Probable cause of problem in threaded build is that nothing calls
Tcl_AlertNotifier(), so the event loop never wakes up.  Note that
Tcl_AlertNotifier() isn't async-signal safe either.

Recommended approach is to use Tcl_CreateFileHandler and the write-to-pipe
technique.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3608957&group_id=10894