Re: possible garbage collector problem...

[Michael McClary <michael>]

> From: mark (Mark S. Miller)
>
> Inter-thread garbage collection in the absence of inter-thread cycles
> should simply result from the combination of garbage collection within
> a thread, weak pointers (from the CommHandler's entry table to
> proxified & proxy objects), and finalization (so the CommHandler's
> table can find out when such an object has gone away, and inform the
> other side).  Inter-thread cycles are a hard problem that I don't
> expect us to need to face for a very long time (hopefully not until
> version 3.0).

If address space becomes a tight resource on a given backend, you can
also have threads respond to a "Try to return some space to the general
pool" message.  The general pool can be managed by a separate thread,
which sends that message, and is also responsible for handing out chunks
to working threads, and keeping track of who might have some to return.

> There
> would be one thread associated with each front-end session, and its
> GCable heap would correspond to the old "session" heap.  In addition,
> there would be a thread for managing the in-core cached form of
> persistent data.  This would be "Urdi write thread", i.e., the backend
> thread that owns the Urdi write view.

Actually, the way to do it is with an "URDI thread" (or perhaps one
URDI thread per URDI device) which responds to messages corresponding
to the public member functions of the current URDI objects.

Any of the frontend-support threads may hold an arbitrary number of
read views (and a max of one write view), in the form of proxy View
objects.  Making the URDI a separate thread automatically serializes
its operation, eliminating the need for mutual-exclusion on its data
structures.

	michael