[lkml]   [2002]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: your mail
On Mon, 25 Feb 2002, Rusty Russell wrote:

> In message <> you writ
> e:
> >
> >
> > On Mon, 25 Feb 2002, Rusty Russell wrote:
> > > First, fd passing sucks: you can't leave an fd somewhere and wait for
> > > someone to pick it up, and they vanish when you exit. Secondly, you
> >
> > Yes, you can. Please, RTFS - what is passed is not a descriptor, it's
> > struct file *. As soon as datagram is sent, descriptors are resolved and
> > after that point descriptor table of sender (or, for that matter, survival
> > of sender) doesn't matter.
> Please explain how I leave a fd somewhere for other processes to grab
> it.
> And then please explain how they get the fd after I've exited.
> Al, you are one of the most unpleasant people to deal with on this
> list. This is *not* an honor, and I beg you to consider a different
> approach in future correspondence.

Actually, this is one of Al's nicest posts :-)
You obviously can't share fd# but you can share file*
I don't know how you're going to have these semaphores 'externally visible',
if with numbers like IPC sems or if with pathnames like unix sockets ( or
something else ). But you can have internally a number/path/else -> file*
mapping and when a task attaches the sem you map the file* onto an fd# in
the task's file table. If you keep this mapping persistent ( until
explicit deletion ) the file* remain alive event with zero attached
processes. I think it's this what Al was trying to say.

- Davide

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.050 / U:9.312 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site