PATCH [multi-env]: convert macros to inline functions

[Max Kellermann <ma...@duempel.org>]

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

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*

08-initialize_default_parsers.patch
- initialize default_parsers explicitly with NULL

09-inline_3.patch
- convert APREQ_BRIGADE_COPY to inline function

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?

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()?

Max

Re: PATCH [multi-env]: convert macros to inline functions

[Max Kellermann <ma...@duempel.org>]

On 2005/02/06 21:31, Joe Schaefer <jo...@sunstarsys.com> wrote:
> +1: lets lower-case them also.

ok. that would have been one of my next patches :)

> 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.

Let's rather make a generic apreq_init(apr_pool_t*)
function. mod_apreq applications must not call this, and CGI or other
standalone applications must call this exactly once (put an assertion
on that). (is that a problem in the Perl glue?)

Passing an apr_pool_t* also enables us to clean up properly. After a
pool cleanup, apreq_init() may be called again.

Max

Re: PATCH [multi-env]: convert macros to inline functions

[Joe Schaefer <jo...@sunstarsys.com>]

Max Kellermann <ma...@duempel.org> 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