httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: [multi-env] t/parsers.c test on Win32
Date Tue, 08 Feb 2005 15:34:00 GMT
Randy Kobes <randy@theoryx5.uwinnipeg.ca> writes:

[...]

> I may be missing something, but does that mean that
> apreq_register_parser(NULL, NULL) effectively returns
> without doing anything?

You are correct, I think.  It should be safe to remove
the "apreq_register_parser(NULL, NULL)" call.

> I tried the following for t/parsers.c:
> ======================================================
> Index: t/parsers.c
> ===================================================================
> --- t/parsers.c	(revision 152645)
> +++ t/parsers.c	(working copy)
> @@ -109,6 +109,10 @@
>
>      /* initialize default-parser hash */
>      apreq_register_parser(NULL, NULL);
> +    apreq_register_parser(URL_ENCTYPE, apreq_parse_urlencoded);
> +    apreq_register_parser(MFD_ENCTYPE, apreq_parse_multipart);
> +    apreq_register_parser(MR_ENCTYPE, apreq_parse_multipart);
> +
>
>      f = apreq_parser(URL_ENCTYPE);
>      CuAssertPtrNotNull(tc, f);
> ================================================================
> and got all the tests to pass. However, I don't understand
> why - I thought this was done in apreq_initialize(),
> which is called by testall.c (and the status checked for
> success).

But we need to check the return values of the apreq_register_parser 
calls, especially in apreq_initialize, because apr threads may 
not be reliable on Win32 (what's your apr version btw)?

I'd start by patching apreq_initialize and seeing what
happens from there.  If we can't identify the bug, 
lets consider either removing the new thread-locking 
stuff or determining which libapr version has reliable 
behavior.

-- 
Joe Schaefer


Mime
View raw message