mehr zu deadlocks (was: linux-l: fork() problem mit omniorb)

[Steffen Dettmer]

* Jan-Benedict Glaw wrote on Sat, Nov 25, 2000 at 15:41 +0100:
> On Sat, Nov 25, 2000 at 03:23:30PM +0100, Steffen Dettmer wrote:

> > Ja, ja, ich weiß, eigentlich sollte ein signal handler primitiv
> > und simpel sein und keine lib funcs aufrufen usw.
> 
> Laß den signal handler nur im "Haupt-Programm" ein flag setzen und
> laß dann den log file entry einfach (etwas verzögert) in der
> select()-Schleife des haupt-Programms machen... 

Ja, schon klar. Hab ich ja auch geschrieben... Nur hat das
"Hauptprogramm" leider keine select Schleife (ist nicht mal das
Hauptprogramm, sondern eben ein  [sub-] Prozeß). Der Prozeß macht
einen blockenden Aufruf. Die Funktion ist auch nicht von mir...
Ergo kann ich schlecht schätzen, ob und wie man die non-blocking
bekommt.

Wie kriegt man eigentlich raus, was man gefahrlos in einem signal
handler aufrufen kann? Kann's z.B. auch bei der [fsv]printf
family probleme geben?

Noch ne jemand Idee?

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.