#1699: Fix network wrt abstract unix sockets
---------------------------------------+------------------------------------
Reporter: [EMAIL PROTECTED] | Owner:
Type: proposal | Status: new
Priority: normal | Milestone: Not GHC
Component: libraries/network | Version: 6.6.1
Severity: major | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Multiple
Os: Linux |
---------------------------------------+------------------------------------
Changes (by duncan):
* severity: normal => major
Comment:
I'd like to point out that this is actually important. Kolmodin didn't
explain what he needs this for, he needs it for the
[http://dbus.freedesktop.org/ D-Bus] library that he has written. The
library is pretty cool. Progress on the lib has been stalled for months
because of this issue.
Instead of using the D-Bus C library he has written a protocol level
implementation in pure Haskell. It works fairly well and is nearly
complete. The D-Bus protocol uses unix sockets and on Linux it uses an
"abstract" unix socket. Normal unix sockets use the filesystem namespace
while "abstract" unix sockets live in a separate namespace. This is of
course a linux only extension but it is nevertheless essential to support
in some manner.
The quirk in the implementation of abstract unix sockets on linux is that
it reuses the same system call as normal unix sockets but one has to
prepend a '\0' to the name. This works because the length of the string
name is given explicitly when making the system call. It doesn't work in
the network lib binding because we assume (not unreasonably) that there
are no embeded '\0' characters in the socket name.
As I see it we have two options, explicitly support them in the API, eg by
providing a linux-only function to open an abstract unix socket, and it'd
handle the prepending of the '\0'.
Alternatively we could not explicitly support this linux-only feature, but
not actively prevent it. We could do the latter by changing the handling
of CStrings in the socket binding so that it uses CStringLen with an
explicit length and therefore allows embedded '\0' characters.
I think I'd advocate the latter approach. It does not change the Haskell
api, it does not affect other operating systems and it does not explicitly
advertise support for this OS-specific feature, but it does not prevent it
from working.
We don't often need this quirky feature but in at least this one case it's
essential. So we need to come to some decision.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1699#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
