You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@hyperreal.org> on 1998/10/18 01:43:20 UTC

FreeBSD 3.0 release notes

In the "changes" section of the FreeBSD 3.0 release notes:

o sleep(3) and usleep(3) are now implemented in terms of signanosleep(2)
  and now have correct SIGALRM interaction semantics and sleep(3) correctly
  returns the time remaining.  Some programs (notably apache httpd) bogusly
  depend on a sleep() "absorbing" a SIGALRM from a timer that expires during
  the life of the sleep.

cause for concern?

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
Nature abhors a vacuum      brian@apache.org      brian@hyperreal.org


Re: FreeBSD 3.0 release notes

Posted by Marc Slemko <ma...@worldgate.com>.
It would be nice if people would think about bringing something up with
the maintainers of software if they thought it was a problem instead of
just throwing arrows from release notes.

Since this hasn't been brought up, it is pretty hard to fix if anything is
broken.

Not very impressive.

Offhand, I have no idea what they are talking about.

On Sat, 17 Oct 1998, Brian Behlendorf wrote:

> 
> In the "changes" section of the FreeBSD 3.0 release notes:
> 
> o sleep(3) and usleep(3) are now implemented in terms of signanosleep(2)
>   and now have correct SIGALRM interaction semantics and sleep(3) correctly
>   returns the time remaining.  Some programs (notably apache httpd) bogusly
>   depend on a sleep() "absorbing" a SIGALRM from a timer that expires during
>   the life of the sleep.
> 
> cause for concern?
> 
> 	Brian
> 
> 
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> Nature abhors a vacuum      brian@apache.org      brian@hyperreal.org
> 


Re: FreeBSD 3.0 release notes

Posted by Marc Slemko <ma...@worldgate.com>.
On Sat, 17 Oct 1998, Dean Gaudet wrote:

> On Sat, 17 Oct 1998, Brian Behlendorf wrote:
> 
> > In the "changes" section of the FreeBSD 3.0 release notes:
> > 
> > o sleep(3) and usleep(3) are now implemented in terms of signanosleep(2)
> >   and now have correct SIGALRM interaction semantics and sleep(3) correctly
> >   returns the time remaining.  Some programs (notably apache httpd) bogusly
> >   depend on a sleep() "absorbing" a SIGALRM from a timer that expires during
> >   the life of the sleep.
> > 
> > cause for concern?
> 
> No, I'm going to assume they're on crack unless they show where the bug
> is.  I just love it when free software projects help each other out.  The
> sharing spirit is so alive.
> 
> "correct SIGALRM interaction semantics" ?  Heh.  All interactions between
> sleep() and SIGALRM are unspecified in the standards.  So doing anything
> is correct, how impressive they got it right. 
> 
> This message contains no sarcasm. 

I think it was more of an oversight and things based on perhaps half or
unjustified opinions, but... sigh.

I have sent mail to jkh/current and we are trying to figure out who wrote
it and what they mean by it.

Note that it isn't even fixed in the FreeBSD port, if it really is broken.
The main reason I am confused is that I can't figure out where Apache uses
sleep() other than in unusual error or other similar cases.


Re: FreeBSD 3.0 release notes

Posted by Dean Gaudet <dg...@arctic.org>.
On Sat, 17 Oct 1998, Brian Behlendorf wrote:

> In the "changes" section of the FreeBSD 3.0 release notes:
> 
> o sleep(3) and usleep(3) are now implemented in terms of signanosleep(2)
>   and now have correct SIGALRM interaction semantics and sleep(3) correctly
>   returns the time remaining.  Some programs (notably apache httpd) bogusly
>   depend on a sleep() "absorbing" a SIGALRM from a timer that expires during
>   the life of the sleep.
> 
> cause for concern?

No, I'm going to assume they're on crack unless they show where the bug
is.  I just love it when free software projects help each other out.  The
sharing spirit is so alive.

"correct SIGALRM interaction semantics" ?  Heh.  All interactions between
sleep() and SIGALRM are unspecified in the standards.  So doing anything
is correct, how impressive they got it right. 

This message contains no sarcasm. 

Dean