The generic parser stores the POST data in the upload
brigade of a param named “_dummy_” but it’s not in
the output table, its in the parser’s ctx pointer.
The struct is declared in parser.c so it’s technically
private but the param is in the first slot and that’s
meant to be public.
On Nov 8,
Finally got some working code. Registered the parser for the content type:
apreq_register_parser(application/json, apreq_parse_generic);
in a pre_init hook, then normal apreq_handle_apache2 and apreq_body calls, then
a apreq_parser_get call to get the parser and:
dummy = *(apreq_param_t
I was looking at a typical apr_thread_create failure for creating a
large # of threads on a system, and the only solution was to increase
roots RLIMIT_NPROC as opposed to the (httpd.conf configured) User
limits
But every manpage I read says that after the setuid(), we should have
the new users
Behavior seems to be that after the setuid, we don't get the new users
limits -- we just get a one-time check to make sure our currently
single-thread process won't push us over the new users' limit.
Confirmed in /proc/$pid/limits on a child in start_threads() that
roots limit is in place.
On
See also PR#55763 -- root has a soft limit of 1024 ulimit -u on RHEL6.
On Sat, Nov 9, 2013 at 7:46 AM, Eric Covener cove...@gmail.com wrote:
Behavior seems to be that after the setuid, we don't get the new users
limits -- we just get a one-time check to make sure our currently
single-thread
On 11/8/2013 12:42 PM, Jim Jagielski wrote:
This has me thinking... we should likely do something to
better error-check the store/restore aspects of slotmem.
Even some sort of quick checksum would be better than
what we have now. :/
Gotta mull this over a bit more.
+1 to that. I couldn't
