By that, I assume you mean that alarms raised in one thread are not caught in other threads.
I mean if you comment out the top set_alarm() statement in my code, it will print "Alarm clock" and exit after 3 seconds. From this I am inferring that the created thread is successfully setting the alarm for 3 seconds. $SIG{ALRM} is set in the same created thread. The problem is the value of $SIG{ALRM} is never used. Instead the magic "Alarm clock" appears and terminates the program!
This was also the first bullet-point of my conclusions:
SIGALRM handlers inside threads are adorably useless. Put the SIGALRM handler in the main thread.
So again, that wasn't my origin message. But since you mentioned it... alarms raised in the created thread were indeed caught by the main thread. In fact, according to my test program anyways, this is the only way alarm signals used in threads are functional at all.
I would avoid using alarm signals in threads altogether. After trial and error, tweaking the code I posted, I have come to understand several nuances of alarm signals and threading. That is what I was trying to share. Hopefully from all the unpredictable behavior I have mentioned, readers can conclude that using alarm inside threads is not worth the headache.
In reply to Re^3: Threads, bash, and networking
by juster
in thread Threads, bash, and networking
by morganda
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |