Guile: passing a file descriptor

Guile: passing a file descriptor

[Marko Rauhamaa]

A PF_UNIX socket can be used to pass an open file descriptor between
processes. However, the relevant control message seems to be missing in
Guile's POSIX facilities (send only accepts a data message).

Am I mistaken, and are there any plans to add control message support to
Guile's library?


Marko

Re: Guile: passing a file descriptor

[Mark H Weaver]

Marko Rauhamaa <marko@pacujo.net> writes:

> A PF_UNIX socket can be used to pass an open file descriptor between
> processes. However, the relevant control message seems to be missing in
> Guile's POSIX facilities (send only accepts a data message).

Indeed, we lack that functionality in core Guile.

> Am I mistaken, and are there any plans to add control message support to
> Guile's library?

I'm not aware of any plans to add it, but if we can agree on an API and
someone contributed a suitable implementation, I don't see why we
couldn't add it.

In the meantime, it's easy to extend Guile with your own bits of C code.

  http://www.gnu.org/software/guile/manual/html_node/C-Extensions.html

You could also probably use our Dynamic FFI to do the job entirely from
Scheme, although we don't have any automatic way of dealing with C
preprocessor macros, so they would probably have to be hard-coded.

  http://www.gnu.org/software/guile/manual/html_node/Foreign-Function-Interface.html

     Mark

Re: Guile: passing a file descriptor

[Marko Rauhamaa]

Mark H Weaver <mhw@netris.org>:

> Marko Rauhamaa <marko@pacujo.net> writes:
>
>> A PF_UNIX socket can be used to pass an open file descriptor between
>> processes. However, the relevant control message seems to be missing
>> in Guile's POSIX facilities (send only accepts a data message).
>
> Indeed, we lack that functionality in core Guile.
>
>> Am I mistaken, and are there any plans to add control message support to
>> Guile's library?
>
> I'm not aware of any plans to add it, but if we can agree on an API
> and someone contributed a suitable implementation, I don't see why we
> couldn't add it.

The C API is really messy. However, after looking at it from different
angles, I'm thinking one shouldn't deviate too far from it. Here is the
germ of a Guile API proposal:

   sendmsg NAME BYTEVECTOR-INPUT-PORT [CMSG-LIST [flags]]
   => integer

NAME is a placeholder and should be set to #f.

BYTEVECTOR-INPUT-PORT may be #f. It captures the idea of the gather
array.

CMSG-LIST may be #f. Otherwise, it is a list or lists. The member lists
have three elements: level, type, bytevector.

To support creating the CMSG-LIST elements portably, auxiliary functions
are provided:

   cmsghdr:make-socket-rights list-of-ports-and/or-fds
   => bytevector

   cmsghdr:make-credentials pid uid gid
   => bytevector

For example:

   (sendmsg #f #f (list (list SOL_SOCKET
                              SCM_RIGHTS
                              (cmsghdr:make-socket-rights (list input-fd)))))


For the other direction:

   recvmsg [BYTEVECTOR-OUTPUT-PORT [flags]]
   => values COUNT NAME CMSG-LIST

BYTEVECTOR-OUTPUT-PORT may be #f. It represents the scatter array.

NAME is a number or #f.

CMSG-LIST may be #f. Otherwise, it is as above.

To support interpreting the CMSG-LIST elements portably, auxiliary
functions are provided:

   cmsghdr:socket-rights bytevector
   => list-of-fds

   cmsghdr:socket-credentials bytevector
   => values pid uid gid

For example:

   (call-with-values
     recvmsg
     (lambda (count name cmsg-list)
       (let loop ((cmsgs cmsg-list) (fds '()))
         (if (null? cmsgs)
             fds
             (loop (cdr cmsgs)
                   (let ((cmsg (car cmsgs)))
                     (if (and (= SOL_SOCKET (car cmsg))
                              (= SCM_RIGHTS (cadr cmsg)))
                         (append fds (cmsghdr:socket-rights (caddr cmsg)))))
                         fds)))))


Marko