cvs commit: src/sys/compat/linux linux_socket.c

[Robert Watson]

On Mon, 7 Mar 2005, Alfred Perlstein wrote:

> Why not just expand our API to do this as well?  It shouldn't be that
> hard and then we'll gain the additional functionality. 

There are some other related MSG_ flag situations we might want to look at
-- for example, the dontroute -> SO_DONTROUTE logic on sosend() where
adding MSG_DONTROUTE would involve racy frobbing of so_options. 

If we do add MSG_NOSIGNAL and other MSG_ flags, it would be nice to avoid
exposing it as a valid flag to sendto/recvfrom in userspace until we
decide we definitely want to expose it as part of the user API, in order
to avoid applications starting to depend on the flags while the details
fall out.

Robert N M Watson


> 
> * Maxim Sobolev <sobomax at FreeBSD.org> [050306 23:26] wrote:
> > sobomax     2005-03-07 07:26:43 UTC
> > 
> >   FreeBSD src repository
> > 
> >   Modified files:
> >     sys/compat/linux     linux_socket.c 
> >   Log:
> >   Handle MSG_NOSIGNAL flag in linux_send() by setting SO_NOSIGPIPE on socket
> >   for the duration of the send() call. Such approach may be less than ideal
> >   in threading environment, when several threads share the same socket and it
> >   might happen that several of them are calling linux_send() at the same time
> >   with and without SO_NOSIGPIPE set.
> >   
> >   However, such race condition is very unlikely in practice, therefore this
> >   change provides practical improvement compared to the previous behaviour.
> >   
> >   PR:             kern/76426
> >   Submitted by:   Steven Hartland <killing at multiplay.co.uk>
> >   MFC after:      3 days
> >   
> >   Revision  Changes    Path
> >   1.56      +25 -2     src/sys/compat/linux/linux_socket.c
> 
> -- 
> - Alfred Perlstein
> - Research Engineering Development Inc.
> - email: bright at mu.org cell: 408-480-4684
>