[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: named ports <-> trivfs translator!

From: Marcus Brinkmann
Subject: Re: named ports <-> trivfs translator!
Date: Mon, 4 Jun 2001 21:36:54 +0200
User-agent: Mutt/1.3.18i

On Mon, Jun 04, 2001 at 02:44:22AM +0200, Johan Rydberg wrote:
> > The canonical way to do it on the Hurd is to attach the server to some node
> > in the filesystem, that means, you write a translator which you attach with
> > settrans, or you write a program that installs itself as a translator
> > somewhere. libtrivfs helps a lot for that.  (For the latter, see how pfinet
> > installs the tunnel "device" in pfinet/tunnel.c (setup_tunnel_device).
> I went with the latter and it seems to work.  Thanks.  Next question:

Note that if you do this, you hard code the file name in the program.  It is
preferable to use the default translator mechanism, where the program is
invoked as a translator with the bootstrap port set.  This is what we expect
from Hurd programs anyway.  Just something to remember if you go from the
testing stage to production quality ;)

> Take a look at the following scenario:
>   1. allocate object
>   2. client does something with object
>   3. deallocate object
> I have created a port class with a custom clean routine.  I want the clean
> routine to be called if the object are NOT deallocated in step 3 (for 
> example, 
> the client dies).  Is this possible - or do I have hold an internal state for
> every port?

AFAICS, the clean routine is always called if the port is deallocated, and
this happens automatically by the kernel if the task is destroyed.  If you
represent the resource as a port, it will be deallocated automatically. 
There is no way for the user to avoid that except staying alive forever.
If you want the user to keep a port and still deallocate the resource, then
you will have to implement this yourself, and check it in the clean routine. 
I believe this is what you mean with the internal state.

I am not that experienced in Mach IPC, maybe there is a way to do what you
want without having another variable.  This would involve the notify server
interface in Mach.  However, I would advise to stick with Hurds libports
(probably extending it if necessary).


`Rhubarb is no Egyptian god.' Debian
Marcus Brinkmann              GNU

reply via email to

[Prev in Thread] Current Thread [Next in Thread]