der Mouse writes:

>>> I imagine the kernel must store this info somewhere since it has to
>>> deliver packets to said process - I guess via the descriptor
>>> table[s].

>> The kernel doesn't store this information, because it doesn't need it
>> during normal operation.  The kernel doesn't deliver the packets to a
>> process.  The packets get "delivered" to a socketbuffer which hangs
>> [off] the vnode.  The first process to read from that vnode [gets]
>> the requested packets.

>Well, there does have to be _some_ link between the two, because a
>process that's blocked in a read or recvfrom on that socket will be
>awakened by arriving data.

But that's just the wait channel, an address.

>But that's probably not useful, because the
>only link between the two is (probably - I haven't specifically looked)
>a sleep/wakeup location pair, which if you wanted to take advatange of
>it would require walking the sleeping process chains.

Right.  And you would only catch the processes currently sleeping on
the wait channel, which is actually a private datastructure and there
are a number of them, depending on whether the process reads, writes,
or selects.  Not very useful.
-- 
Christoph Badura	bad@flatlin.ka.sub.org

You don't need to quote my .signature.  Everyone has seen it by now.
Besides, it doesn't add anything to the current thread.