Re: Serious Bonobo Problem for Sun

[Colm Smyth <Colm Smyth Sun COM>]

>Delivered-To: gnome-components-list gnome org
>To: Colm Smyth <Colm Smyth Sun COM>
>Cc: darin eazel com, michael ximian com, mjs eazel com, miguel ximian com, 
brian cameron ireland sun com, gnome-components-list gnome org, 
Brian Cameron Sun COM
>Subject: Re: Serious Bonobo Problem for Sun
>From: Soeren Sandmann <sandmann daimi au dk>
>User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
>MIME-Version: 1.0
>X-BeenThere: gnome-components-list gnome org
>X-Loop: gnome-components-list gnome org
>X-Mailman-Version: 2.0beta5
>List-Id: component/document model <gnome-components-list.gnome.org>
>
>Colm Smyth <Colm Smyth Sun COM> writes:
>
>>    client; this mechanism requires each object server to maintain a
>>    timeout value and a last-invoked time for each of it's clients; this
>>    could be done globally or for each object instance in an object server 
>
>Does the server have to maintain anything but a time-to-die timer?
>When the server is created, the timer is set to some suitable value,
>and the lease renewal code could look something like:
>
>void Server::renew (unsigned int n_secs)
>{
>    time_to_die = MAX (time_to_die, n_secs);
>}
>
>This should guarantee that the server never dies within the time frame
>that a client has requested it stays alive.  When the timer expires,
>the server can safely commit suicide.

If the server has multiple clients, then there are multiple time-to-die
values to track, one for each client. This assumes we want to support
Bonobo reference-counting; if we dropped ref-counting in favour of
a pure lease system, then the server would simpy track a single
time-to-die value (which would be the longest time-to-die offered
by any client requesting a lease on an object).

Colm.

>_______________________________________________
>gnome-components-list mailing list
>gnome-components-list gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-components-list