> > Alan, the current code in net/af_unix.c silently discards messages
> > with zero length of data part, even if they do contain cmsg's. Does
> > something terrrible a-la POSIX require such behaviour? If it doesn't I
> > have a patch for you ;-/ I think that current behaviour is wrong, because
> > a) if all we are going to do is to pass some descriptors, well,
> > sending some dummy data seems klugy.
>
> Nod. For portability its needed on other platforms too
?Parser fault
Not sure that I understood you right. Actually I found that
kuldge/feature/whatever when I wrote a testcase for bug in FreeBSD garbage
collector[1]. *BSD (at least FreeBSD and SunOS) allow sending such
messages.
Do you mean that by portability reasons we should keep that as is,
maybe adding some flamage on return?
> > b) even if such messages should be discarded it's not too nice to
> > discard them silently.
> Ok.
> > c) discarding such beasts for SOCK_STREAM and allowing them for
> > SOCK_DGRAM sounds wrong.
> You can't return a 0 datagram for SOCK_STREAM. 0 is EOF on a stream.
Hmm... I'll look through the code - probably the best thing to do would be
to postpone cmsgs till the next nonempty message / end of connection. What
do you think about that variant?
Cheers,
Al
[1] Duh. I decided to look how BSD stack deals with circular references in
garbage collector. They used to have the very same bug. Fixed it back
in '91. Then I looked through their fix. Yeah, right. Exactly the same bug
as in the first version I've written - silently discards queues of some
sockets. The same reason - they don't scan queues of listening sockets.
One more patch to write... BTW, their mark phase is terrible - scan over
the whole list of open files. Many times. Furrfu...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/