Subject: Re: [htdig3-dev] Alarm clock
From: Gilles Detillieux (firstname.lastname@example.org)
Date: Mon Feb 28 2000 - 12:42:37 PST
According to Gabriele Bartolini:
> >A handler for SIGALRM? I believe the default action is to terminate the
> >process, so if that's not what you want, you need to set a handler for it.
> That's just what I wanted to say. As far as I am concerned, we don't need
> any handlers, do we?
Yes, we do. I just looked at the man page for signal(7), that lists
the default actions for each. The default for SIGALRM is to terminate
the process, which is exactly what is happening to htdig. Obviously,
we don't want this. It's also pointless to set the action to ignore the
signal, as that would defeat the whole purpose of setting the alarm. So,
the only option left is to define a handler for the signal, and set up up
such that the connect() call does not resume after the signal is handled.
> >You should probably take a look at how other TCP/IP clients handle this
> Any indications?
No, I can't think of any examples off-hand, but it seems to me that there
ought to be source code out there for clients that do handle this situation,
so it if you can find any, it may serve as a good example to follow.
One of the pitfalls to look out for is the SysV vs. BSD signal handling
paradigms, as one of them will cause the system call to resume after the
signal is caught and processed, and the handler returns. We don't want
this to happen, so we need a portable way of dealing with the signal on
the various platforms we support.
-- Gilles R. Detillieux E-mail: <email@example.com> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil Dept. Physiology, U. of Manitoba Phone: (204)789-3766 Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------ To unsubscribe from the htdig3-dev mailing list, send a message to firstname.lastname@example.org You will receive a message to confirm this.
This archive was generated by hypermail 2b28 : Mon Feb 28 2000 - 12:46:58 PST