httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: Thoughts on implementing mod_status in MPM...
Date Sat, 07 Aug 1999 03:01:32 GMT
On Thu, Aug 05, 1999 at 04:26:35PM -0700, Dean Gaudet wrote:
> As long as you're not requiring all MPMs to do this with shared memory... 
> I'd really like to leave the stage open for an MPM to do it in whatever
> way makes sense for their platform.  Which is why I'm advocating
> get_first/get_next for mod_status. 

I'm only talking implementation, not interface. I don't want to
mandate shared memory either.

> Remember also, that this is mod_status, and 1 second old data is perfectly
> fine.  So it could just be that the processes copy their scoreboards up to
> a central process when asked... and the mod_status requests for the next
> second are satisfied from that central process. 

It's a possibility, but shared memory is easier. :)

> I think my main concern with the multiprotocol stuff is that it gets us
> into the realm of variable length data... which makes all of this hard.
> Unless we just decide that there are 80, or 132, or 160 bytes to play with
> per connection and let each protocol format things in whatever way they
> want.
> It's a tough problem isn't it? 
> It's worthwhile studying how "ps" works in various unixes... since it's
> roughly an equivalent action.

The problem in this case is harder though. ps only has a single type
of entity to report on (processes) which all have the same data
reported. It's more like the 1.3 mod_status.

The ps implementations either use /dev/kmem to examing
kernel memory, or they examine /proc.

Manoj Kasichainula - manojk at io dot com -
"Very sad life. Probably have very sad death. But at least these is
symmetry." - Zathras in _Babylon 5_

View raw message