Sergio
> Unfortunately I was not using the <unistd.h> header in my C
> application, I tried adding this header and it didn't make a difference...I
> assume then that without the unistd.h my application was using the shell
> version of sleep, is there a difference with the shell sleep and C's
> sleep(1); ?
Actually no. The shell version of sleep is a stand-alone program.
You would never get a shell version of anything when compiling a C
program regardless of header files. The only way to get a shell
program would be to call it explicitly using the system(3) call in
something like system("sleep 1"); but you were not using system and
would not want to either.
Basically the shell sleep will call the libc sleep just like your
program does. It is all of the trappings around it that are
interesting and would be different in different programs.
> Basically this is what my loop looks like in my application: (I'm
> only including sections of the code that are relevant to your
> understandings.)
That looks like a good structure. I did not test it out on my end but
on the surface it looks like it should work. My manual for sleep says:
: + Any caught signal terminates the sleep following execution of
: that signal's catching routine.
So your trap handler should be executed. The variable should be set
and the loop should terminate.
> I tried the targeted test of just sleep and I also got 130 on my machine,
> the version of sleep is sh-utils 2.0
So it sounds like the sh-utils stand-alone program sleep is working
fine for you. Which means that you probably need to work with the
glibc folks to understand the sleep(3) routine (sleep from section
three of the manual which means the C library) and to understand why
your trap handler in your C program is not getting called during a
sleep() library call. I can only imagine that there is undesirable
interactions between sleep and signal trap handling. I would try the
newest version of glibc first and see if the behavior is different.
Good Luck!
Bob
