Please consider renaming Sockets.PipeServer or provide a better named alias

Internals & Design
1

Being new to posting here, I had to put my rationalization over in [Usage].(Sockets.PipeServer serves named sockets not named pipes) Sorry if cross-posting is frowned upon but I thought posting here might be more likely to bring the issue to the attention of the right people.

In summary, at least on Linux, named pipes (FIFOs) and named sockets (AF_UNIX) are completely different gizmos. Other than being named and providing a communications channel they have very little in common.

Julia is great for learning and experimenting with IPC, but the name PipeServer is misleading at best. I’m far from new with sockets or even Unix-style computing but I am relatively new to Linux (just celebrated one year of using Linux full-time :slight_smile:). Sockets.PipeServer initially made it harder for me to get the two concepts of FIFOs & AF_UNIX sockets straight in my head.

2 Likes
2

Fair enough. The naming follows libuv’s uv_pipe abstraction, which abstracts over AF_UNIX on unix and Windows Named Pipes on Windows (and ReactOS I suppose :wink: ). If you have suggestions for an improved API naming, I’m happy to take them. The whole socket API needs an overhaul for 2.0 anyway, so might as well collect these things.

3

Thank you @Keno for looking at this. I had noticed that it was based on libuv, but hadn’t studied libuv deeply enough to understand the naming.

Maybe Sockets.listen(path::AbstractString) should return a Sockets.NamedServer. The docstring for listen should then explain that the underlying mechanism of NamedServer depends on the OS and at least name the mechanisms for the OSes on the major platforms on which Julia runs.

For the casual Sockets user, things should work as before. For someone learning how to do IPC using Julia, these changes would be very useful. The most grief would be for those subclassing or dispatching on Sockets.PipeServer. However, if 2.0 is going to introduce a new Sockets API, that’s going to be true anyway.