perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [mp2] read/write access to server/process records (+patches)
Date Tue, 10 Feb 2004 01:30:01 GMT
Geoffrey Young wrote:
>>>in general, I don't agree with this - modifying several of the server_rec
>>>slots at request time is something that some (few) mp1 user required.
>>Did they wanted to affect the server for the future requests, or just
>>the current request?
> the only value I see is in scoping server_rec features for the current
> request.  if they mean to change things for the entire server across
> requests then there is no contention.

That's exactly what I was suggesting. And therefore asking whether you want 
the set() accessor to affect the server across requests or not. You just said 
that mp1 users are required to restore any changes at the end of request. 
Doesn't it make it local?

>>>however, threaded environments continue to represent an endless shift
>>>in the
>>>way we typically think of doing things.
>>>I think one solution that I offered at ApacheCon was to allow
>>>of server_rec slots and other server attributes under unthreaded mpms and
>>>read-only under threaded mpms.  I still think this offers a happy medium
>>>between the two - if you require request-time modification of server
>>>attributes, either use prefork or rethink your requirements.
>>I don't find this a happy medium. An application/module developed on
>>prefork mpm won't work on threaded mpm, e.g. cutting off windows users.
> but we have that limitation already, and will continue to have it in that
> threaded environments are limited to threadsafe modules.  if an application
> requires threads, the developers are forced to make different decisions anyway.

what different decisions you are referring to, Geoff?

>>My definition of the happy medium is to provide the API that works
>>indentically everywhere, and not create a burden for the developers to
>>check their modules/apps on a bunch of platforms. It's possible that the
>>threaded implementation will be slower, but it should work all the same
>>from the user point of view.
> sure, that's the ideal.  however, I find it difficult to accept that we keep
> _all_ users away from certain parts of the API because _some_ environments
> can't handle it.  of course, with properly implemented mutexes it becomes
> possible, but at what cost to the maintainability of the codebase I wonder?

But we already go through the pains of supporting threads, and already have 
the maintainability overhead, I don't think that another mutex will make much 
of a difference.

what is the point of even spending any time on the threaded mpms, if people 
won't use them, since modules/apps won't run on them?

>>If the server_rec mods are required only
>>for the current request, perhaps introducing a concept of localized
>>server_rec is needed.
> perhaps, but that would involve a magical layer that isn't required in
> prefork, so long as you remember to set the server_rec back to its original
> state.  the real problem is threads.

actually that won't quite work. I was thinking to have localized values just 
for the user calls (when they ask to retrieve the data), forgetting that the 
real server_rec needs to be updated too.

obviously threads and writable server records don't go together, since we 
introduce the cwd-syndrom problem.

as for non-threaded mpm, I think it'd be cool to let users change the server 
rec, w/o requiring them to restore it. We could register request cleanup 
handler which will restore the original values.

>>Also some server_rec records could be safely modified at the startup,
> sure.
>>that's another reason for reviewing what should be r/o and what r/w. So
>>startup and request time modifications are two different things, and
>>should be each addressed separately.
> with the addition of substantial complexity.

But it's a necessary evil, no? If you have a perl API to configure the server, 
why forcing people to use the ugly add_config("Foo bar"), when they can say a 
more perlish $s->foo('bar')?

we could even have two functions for each accessor and fiddle with function 
pointers, reinstalling the r/o implementation after the server startup.

>>But doing:
>>  $r->server->add_config('KeepAlive On');
>>at request time, is not forbidden by the API, no? 
> I would have thought that both this and ServerAdmin would have been
> prevented due to their RSRC_CONF implementation - my experience let me to
> believe that this was exactly equivalent to an .htaccess file, with the same
> restrictions.  but cleary it works in TestCompat/ so I guess I'm
> wrong about something.

I wrote that as a random example, w/o checking on it. My point is that we need 
to make sure that direct accessor API and config API should match. If you can 
run $r->server->add_config('KeepAlive On'); at request time, you should be 
able to do $r->server->keep_alive(1); and vice versa.

>>Or is it only mod_perl
>>which exposes add_config to users, and thus makes it easy to do unsafe
> I don't see anyplace in httpd core that uses ap_build_config at request time.

but as you say $r->server->add_config is the exact equivalent of .htaccess, so 
we can't go wrong here. (exact, minus the timing: .htaccess is run at around 
trans handler, whereas add_config may run much later into the request phases.

Also it looks like it allows only a limited number of Apache core directives:

> in general I think that, like many things which become popular beyond their
> original scope, the Apache API was never designed to be subjected to the
> many things we twisted Perl people do with it.  for the most part Apache
> handles the strain well, but in cases like this we may be pushing it beyond
> its intention.  cool :)

so may be we should tighten things up in mp2, now that it's no longer safe to 
using the Apache API beyond its scope?

>>I was talking about structs we have no experience with. I thought we
>>have agreed that won't be able to go through every possible
>>method/accessors apache/apr provide and mark only those supported as a
>>2.0 API and the rest 'experimental'.
>>I was just suggesting that it's safe to turn all those 'experimental'
>>accessors, read-only and then add the write access if we learn that it's
>>needed, as it won't break any one's code.
> I'm still not entirely sure I agree with that - it seems like we would then
> be in the same position as mp1 wrt adding features piecemeal.  but let's
> discuss that another time :)


>>>>+<  port
>>>>+<  loglevel
>>>I've required write access to these in the past
>>Sure, I can see the use for loglevel, but it should be local to the
>>request, right?
>>What about the port? Can you give an example of why would you want to
>>change it? Doesn't make much sense to me, since you are already
>>listen'ing to port value. Unless you try to hop to another vhost.
> whoops, that was supposed to be timeout, which would be useful to set on a
> per-request basis for an operation you know to be long-running.

Yes, indeed that was very useful in mp1. Perhaps there are other ways to 
handle that in mp2.

>>>>+<  keep_alive
>>>I can see write access to this being useful
> none that I can think of at the moment.  and I suspect that you could always
> force the issue by setting "Connection: close" in the headers, and you
> probably wouldn't want to unset it for non-HTTP/1.1 clients.

Oh, you mean if you have keepalive by default on, but want to turn it off for 
this request. But I don't think this is a right solution at all. If you turn 
it off, you affect all other future requests. Where would you have turned it 
on again?

> but again, I'm a "if you build it, they will come" kind of guy and don't
> believe in cutting off parts of the API just because we can't immediately
> see the benefit.  closing off dangerous parts, of course.  but other than
> that I'm in favor of an open API, even if it means users can shoot
> themselves in the foot sometimes.  there are always learning curves :)

I say, let's take it in a baby steps and finish a sub-set of a safe API and 
release 2.0, then incrementally expose new things.  mp1-1.0 didn't have all 
the features mp1-1.29 has.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message