httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: Comments on accept-mutex/single-listen patch ??
Date Tue, 28 Aug 2001 14:18:00 GMT
Jim Jagielski <jim@jaguNET.com> writes:

> Anyone get a chance to look over and try out the latest patch?
>                    will lose both and deserve neither"

I still have unanswered questions from the post of the first patch.
Here they are again, hopefully with the now-resolved issues trimmed
out.

Thanks,

Jeff

-----------/-----------
Jim Jagielski <jim@jaguNET.com> writes:

> Comments are welcome... I'd like to commit the patch this week. At
> that point, we port to 2.0, which already has a lot of the
> work done (just need to do the default stuff and handle SingleListen)

which "default stuff" is needed in 2.0?

why is SingleListen needed?

> @@ -433,6 +433,9 @@
>  #define JMP_BUF jmp_buf
>  #define USE_LONGJMP
>  #define USE_FLOCK_SERIALIZED_ACCEPT
> +#define USE_FCNTL_SERIALIZED_ACCEPT
> +#define USE_NONE_SERIALIZED_ACCEPT
> +#define DEFAULT_SERIALIZED_ACCEPT_METHOD flock
>  #define SINGLE_LISTEN_UNSERIALIZED_ACCEPT

So what decides when "USE_NONE_SERIALIZED_ACCEPT" is a choice?  I'd
think that if you allow it anywhere you'd allow it everywhere, and
that there'd be no need to define anything in ap_config.h.

> ===================================================================
> RCS file: /home/cvs/apache-1.3/src/include/http_main.h,v
> retrieving revision 1.36
> diff -u -r1.36 http_main.h
> --- src/include/http_main.h	2001/01/15 17:04:34	1.36
> +++ src/include/http_main.h	2001/08/20 18:19:42
> @@ -130,6 +130,11 @@
>  
>  void setup_signal_names(char *prefix);
>  
> +/* functions for determination and setting of accept() mutexing */
> +char *default_mutex_method(void);
> +char *init_mutex_method(char *t);
> +char *init_single_listen(int flag);

prefix with "ap_"...  yeah, not everything in 1.3 is
namespace-protected, but it is trivial for new functions.

> +		return "Request serialized accept method not available";

"Requested", not "Request"

> +		return "Request serialized accept method not available";

same as previous comment, but I'd think one of these should never
fail... how about ap_assert() in one of them instead of returning an
error that we shouldn't have logic to check for?

-----------------/--------------

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Mime
View raw message