perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: [mp2] read/write access to server/process records (+patches)
Date Tue, 10 Feb 2004 00:53:12 GMT

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

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

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

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

> Also some server_rec records could be safely modified at the startup,


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

> Or is it only mod_perl
> which exposes add_config to users, and thus makes it easy to do unsafe
> things?

I don't see anyplace in httpd core that uses ap_build_config at request time.

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 :)

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

>>> +<  keep_alive
>> I can see write access to this being useful
> Examples?

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.

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 :)


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

View raw message