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: Chris Pressey <cpressey@xxxxxxxxxxxxxxx>
Date: Thu, 29 Apr 2004 10:27:10 -0700

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.

>     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.

OK, one more question: do you plan on having support for linked lists
(trees, etc,) in the encoder/decoder at some point?  I realize you can't
support every possible data structure (since C, naturally, carries no
type metadata in a program, and there are just too many possibilities,)
but the more common structures might be nice.

I definately have an interest in these two issues, so I'll be glad to
help out with anything that's within my grasp.  For now, I'm just
working around them to see if/how it "can be done".

-Chris



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