[m-rev.] for review: deep profiler redesign

[Ralph Becket]

Zoltan Somogyi, Tuesday, 12 November 2002:
> On 11-Nov-2002, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> > I was wondering why it wouldn't have been easier to have just one
> > long-lived server process that just dumped a client's state on a
> > timeout?
> 
> What state? The clients don't have any state.

The server(s) carry around state pertaining to their clients.

> The profiling data file itself is the only compact representation we have
> of the information contents of the server. There is no point in writing that
> out; it already exists on disk.

When I wrote "dumped", I meant "threw away."

> One server won't work anyway; you need one per profiling data file. That's why
> the timeout period is short: it reduces the probability that more than one
> need to be alive at a time. This is important, because several of these servers
> will probably run one of our machines out of virtual memory.

There's no reason you *couldn't* have one server handle all data files.
That may or may not be a good idea.

My thought was that a single process could act as a server for all
profile browsing.  After a given period of inactivity from a client,
it would discard any state associated with that client, thereby freeing
up those resources.  Some mild cunning would be required to release
freed virtual memory, since you say that's a problem.

> > Then you'd only have to handle the start-of-day race
> > condition.
> 
> So you'd want to exchange a pair of solved race conditions for one unsolved
> one, so you could switch to an approach that requires a lot more resources?

Er, I don't follow your reasoning.  You've solved the start-of-day race 
condition, and that solution would work just as well for a single-server
approach.

Assuming one can return freed resources to the OS, one server could
handle several sessions and persist as a process for some time.

However, if as you say a server may consume gigabytes of VM in serving a
single client, then this is not a sensible approach.  But that's the
explanation I was asking for!

- Ralph
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------