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

[Zoltan Somogyi]

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

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.

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

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