Re: Threads

[Jason Gunthorpe <jgg@gpu.srv.ualberta.ca>]

On 23 Oct 1997, Manoj Srivastava wrote:

> 	This causes alarums to go off in my head. I have seen a lot of
>  peoducts being re-engineered to be distributed/multithreaded, and in
>  the majority of them it was less costly to redesign/rewrite. 
> 
> 	Good multi-threaded code is as much of a paradigm shift as OO
>  methodology is. Would you say that a procedural program can be made
>  OO later on? 

This is true, but from our discussion and the tree nature of a widget set
I think we don't have many choices for any sort of fine grained locking.
No matter what we do it will be inefficient to some degree :< So I think
it is better to go for simplicity.. Did you read my latest post on 'one
big huge mutex' (The extreme of the inefficient scale)?

> ps. Look at Using signals with POSIX threads, at
> <URL:http://developer.austin.ibm.com/sdp/library/aixpert/aug95/aixpert_aug95_signal.html>,
>  from AIXpert Magazine's August 1995 issue

Thanks! This is a wonderful article. This means we can lose the last
BSDism in the code and use a thread to break the select loop and safely
deliver SIGWINCH to the slang library. 

However, that article didn't seem to be clear what happens in the case of
sigsegv (sync signals)? We need to reset the terminal in this case and
exit. 

Slang actively manipulates the signal mask of the process as it runs so
you can safely write code that calls it's cleanup routines from a signal
handler. I think from that article that doing so will prevent delivery of
those signals to any thread?

Jason