DragonFly BSD
DragonFly bugs List (threaded) for 2004-04
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: troubles with caps


From: Dave Leimbach <leimySPAM2k@xxxxxxx>
Date: 29 Apr 2004 15:09:53 -0500

Chris Pressey <cpressey@xxxxxxxxxxxxxxx> writes:

> On Sun, 25 Apr 2004 18:04:38 -0700 (PDT)
> Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > 
> > :I've been playing with it quite heavily in the past few days and I
> > like:it a lot.  I have two questions about it though, if you don't
> > mind::
> > :Do you have any plans to introduce a timeout to (say) caps_sys_wait,
> > so:that if a message doesn't come in in a certain time frame, it
> > returns:with errno == ETIMEOUT or similar?
> > 
> >     I've been thinking about tying it into the file descriptor
> >     subsystem but there are issues related to programs fork()ing and
> >     closing all descriptors that makes it difficult for a libc
> >     implementation to properly deal with the fork.
> 
> This would be very, very handy, if for no other reason than quite a bit
> of existing software, like GTK, makes the assumption that select() is
> how you're going to wait on events.

Hmm that seems like a problem with GTK.  What about kernel queues?i

> 
> >     But, yes, I think we do need some sort of timeout feature.
> > 
> > :And, when the process which is holding a connection dies, does that
> > :connection die too?  From the looks of the client example (which
> > forks):I'm guessing no, the connection sticks around and can be shared
> > by:several processes.  But is there a guarantee of that?  Say I'd like
> > to
> > 
> >     The connection is actually NOT shareable between processes that
> >     fork().  What happens when you fork is that a dummy placeholder
> >     connection is created in the child so if the child tries to access
> >     the CAPS descriptor it gets a specific error that it can check for
> >     and know when to reconnect.
> 
> Ah, so that's what client.c is doing.  OK, well there's no good reason
> to share the connection; I just wanted to clarify that limitation.
> 

Yeah... servers are one to many clients.  No two servers should have
the same name, though the current code allows it... Hiten has a patch
that seems to work though :).


Dave



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