DragonFly bugs List (threaded) for 2004-04
Re: troubles with caps
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 :).