Thready a signaly

[Ales Pour]

> da komunikace mezi thready ridit synchronne (pres synchronizacni 
> objekty, zpravy, sdilenou pamet apod.) a kdy potrebuju neco 
> asynchronniho (typicky - i kdyz to neni prilis caste - potrebuju 
> utnout thread a uklidit po nem; pokud by thread mel signal handler a 
> v nem vratil, co si alokoval, bylo by to silne jednoduche). 
> Asynchronni neni potreba casto ale IMHO existuje par pripadu, kdy se 
> bez nej neobejdu.

Co vsechno je dobry delat v signal handleru? Co nejmin. Prikladam co
napdal D. Butenhof pred casem v comp.programming.threads (sledoval jsem to
mozna protoze jsem resil podobny otazky)

--------

> > Right; but signals aren't control flow. They are a sort of inter-process
> > communication mechanism. Don't know about Ada, but from the description
> > it sounds as if there are really two exceptions going on. The processes
> > rendezvous, presumably, by invoking some rendezvous operation. This operation
> > gives rise to an independent exception in both callers.
>
> I don't know much about signals, but it seems that being able to raise an
> exception in another thread is a potentially very useful mechanism at times.
> Unlike the usual communication mechanisms, remote exception are async. instead
> of sync (the thread in which the exception is raised in not in any particular
> synchronization point at the moment the exception is raised).

Yeah, it sounds convenient. However, it also breaks most of the basic design
principles of threaded programming, and ruins some of the important advantages.

With threads, multiple streams of control do things concurrently and SYCHRONOUSLY,
rather than trying to do things asynchronously within a single stream of control.
This substantially simplifies the job for everyone.

So what's the point of adding the ability to asynchronously "tug" at the stream of
control in other threads? You should be trying to do whatever it is you need
synchronously, possibly in a third thread, but certainly not overloading and
yanking around an existing independent thread.

Most POSIX functions are not "async signal safe" because allowing them to be so
makes them substantially more expensive and "heavy" -- and therefore less useful.
If you expect to do much in the handlers for an asynchronous exception, then
whatever you do must be based on async-signal safe functions. You're either
tremendously limited by the current list of such functions, or you'd need to
substantially increase the list.

/---------------------------[ Dave Butenhof ]--------------------------\

A konkretne - pokud jde o utnuti threadu, tak se daji pro jednodusii
pripady pouzit cleanup funkce (pthread_cleanup_push/pop - a pokud jste
chtel vsechno uvolnovat v signal handleru tak to mozna je vhodne); pro
slozitejsi (treba v C++ pri hojnym pouzivani STL kontejneru - muj pripad
:]) si proste udelat vlastni mechanismus cancelovani a na pthread_cancel
apod. se vykaslat. To neni moje moudro ale zaver, kterej jsem si pro sebe
udelal ze vsech odpovedi na moje otazky na tyhle veci co lidi napsali v
c.p.threads.
Hezky den,
	Ales Pour