httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: PATCH [multi-env]: convert macros to inline functions
Date Sun, 06 Feb 2005 20:31:57 GMT
Max Kellermann <> writes:

> 05-inline_1.patch
> - convert APREQ_RUN_PARSER and APREQ_RUN_HOOK to inline

+1: lets lower-case them also.

> 06-remove_memmem.patch
> - remove the apreq_memmem function
> 07-inline_2.patch
> - convert apreq_(un)escape to inline
> - apreq_escape does not create apreq_value_t*

+1 to both.

> 08-initialize_default_parsers.patch
> - initialize default_parsers explicitly with NULL

static vars are always initialized that way, IIRC.
+1 to making it explicit though.

> 09-inline_3.patch
> - convert APREQ_BRIGADE_COPY to inline function

Should become lower-case as well.

> The multi threading issue with default_parsers is still not
> fixed. This is difficul because we can't use an apr_thread_mutex_t
> easily: it has to be initialized with a function, not statically. Same
> race condition with the mutex initialization. Any ideas?

I don't know of any realistic way to make default_parsers thread-safe.
I think we should just expose an apreq_parser_initialize and let
someone else worry about the thread-safety issue.  IMO there's really
no good reason for an application to call apreq_register_parser() after 
server startup, so I don't think we need to worry about that.

> apreq_parser() does not call apreq_parser_initialize(). Applications
> have to call apreq_register_parser(NULL,NULL) before they can use the
> parsers. Why don't we just add an apreq_parser_initialize() call to
> apreq_parser()?

+1, but again, libapreq2 applications should call this once per-process,
not once per-request.  mod_apreq apps should't need to call it ever.

Joe Schaefer

View raw message