[linrad] Re: Error exit

[Frank Brickle <brickle@xxxxxxxxx>]

Leif --

> Ok, what about threads waiting for keyboard, mouse events,
> network input or other I/O functions?
> I have set the parameters for CANCEL_ASYNCHRONOUS and
> put start and stop of hardware drivers in the main routine.
> Do you see any problem with that?

I'd need a little more detail before answering with 
certainty, but in general it should be fine. CANCEL_DEFERRED 
is probably what you want in order to achieve termination at 
neat and convenient points.

> What about threads that do not exit explicitly, the ones
> killed by pthread_cancel() from the thread having the thread
> killing as its single task?
> It it safe to join only the thread that has killed all the others?
> There are many different modes of operation with different threads 
> running and it would be nice to not have to keep track of everything
> under error exit conditions;-)

That should be OK too. A typical thing to do would be to 
maintain an array of thread IDs. The killing thread would
simply loop through the array, cancel each of them in turn, 
(except itself, of course) and then do a join on the one 
just cancelled. Or it could do a cancellation loop and then 
a join loop. The order isn't particularly important with 
CANCEL_DEFERRED. It would then simply exit to a join in the 
main routine.

> Ctrl C is doing something, is it impossible to do the same from
> within an arbitrary thread within the program?

Yes. You need to trap the Ctrl-C by having a signal handler 
thread catching SIGINT. Man sigblock. It's a little 
complicated but really only needs to be worked out once :-) 
The protocol is slightly more complicated than for 
traditional signal handlers since you need to localize which 
thread receives the signal. Also, signals trapped with 
sigblock are "reliable" in the sense that they are never 
dropped in a race condition, unlike traditional signals.

> What happens if I join threads that have already been killed?
> (In case it is unsafe to join only the "kill everything" thread?
> The code is intended to be portable to MS Windows and
> Macintosch...

A join on an inactive thread merely returns immediately. No 
danger.

The arrangement, except for the SIGINT signal handler, 
should be the same in any environment that supports 
pthreads. The port to Mac OSX should be immediate.

One of the advantages of using a gui environment like KDE or 
gtk is that all of these details are hidden behind the 
environment-specific event queuing and delivery mechanisms.

73
Frank
AB2KT



#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>

LINRADDARNIL