[Top][All Lists]

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

Re: About SOCK_CLOEXEC, SOCK_NONBLOCK flags, accept4, etc.

From: Thomas Schwinge
Subject: Re: About SOCK_CLOEXEC, SOCK_NONBLOCK flags, accept4, etc.
Date: Tue, 9 Dec 2008 15:24:51 +0100
User-agent: Mutt/1.5.11


> +int
> +accept4 (fd, addrarg, addr_len, flags)
> +     int fd;
> +     __SOCKADDR_ARG addrarg;
> +     socklen_t *addr_len;
> +     int flags;
> +{
>    error_t err;
>    socket_t new;
>    addr_port_t aport;
> @@ -43,6 +61,10 @@ accept (fd, addrarg, addr_len)
>    mach_msg_type_number_t buflen;
>    int type;
> +  /* TODO.  Have to pass the flags to __socket_accept -- means adding a new
> +     socket RPC accept4 AIUI.  */
> +  /* TODO.  pfinet / pflocal changes.  */
>    if (err = HURD_DPORT_USE (fd, __socket_accept (port, &new, &aport)))
>      return __hurd_dfail (fd, err);

... and similar for all socket-creating RPCs.

I wonder whether we should really go this route and do changes to the RPC
interface (and implementations of pflocal and pfinet) at all or whether
we can rather achieve the desired user-level atomicity of creating a new
FD and setting its initial flags (O_CLOEXEC and O_NONBLOCK are currently
considered) by using some glibc-level blocking mechanism?  (Would
HURD_CRITICAL_BEGIN and frieds be the ones to use?)  The two cases are
illustrated on
<http://udrepper.livejournal.com/20407.html?thread=108471#t108471>.  If
this is possible, doing so would save us from having to do any changes to
the socket RPC interface, as far as I can see.  But also it would mean
that programs that directly use the socket RPC interface would have to
reimplement that functionality.  (That last argument being a non-one, in
my opinion, as there aren't any such programs.)  Or is it better /
cleander / more future-proof to introduce new RPCs?  Roland?


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]