| |||||||||||||
Review: The Linux Programming InterfaceReview: The Linux Programming InterfacePosted Jan 21, 2011 15:00 UTC (Fri) by price (subscriber, #59790)In reply to: Review: The Linux Programming Interface by RobSeace Parent article: Review: The Linux Programming Interface
The reason abstract-namespace sockets are evil is that everything you end up wanting to do to them has to be reinvented, or else you live without. If on the other hand you use a common abstraction, namely the filesystem, then you get the benefit of all the common tools.
Cyberax's examples of the things you want to do include
Here's my example:
If the clvmd authors had used filesystem sockets like good Unix-respecting developers, I could have simply mv'd or even rm'd the old socket, and the new process would have been free to bind to its socket at the usual name. Instead, I had to restart the box. This was a VM server -- dozens of people's VMs were affected by each restart. The bug recurred a couple of times a day. I *really* wished the program had used sockets in the filesystem, or that somebody had implemented rename() or unlink() for abstract-namespace sockets -- but who would do that? The program should have used sockets in the filesystem.
If you're unhappy because a system leaves files around in /tmp that aren't used anymore, you're really focusing on the wrong things.
(Log in to post comments)
Review: The Linux Programming Interface Posted Jan 21, 2011 15:39 UTC (Fri) by RobSeace (subscriber, #4435) [Link]
> examples of the things you want to do include
No, I want to do none of those things... Maybe they are things YOU and others want to do... But, personally, I have no need for any of them, and they mostly seem like stretches and grasping at straws to justify them existing in a place they certainly don't belong (the filesystem)...
And, your example of a buggy app and/or kernel is just crazy... You want to be able to kluge around a serious app/kernel bug by stealing its socket out from under it, and replacing it via another running copy? How about just fixing the bug! What if it were holding a TCP port# instead? Do you complain that you can't "rm" listening TCP ports, too?
> If you're unhappy because a system leaves files around in /tmp that aren't used anymore
That's part of why I dislike them... They're scattered around wherever, often somewhere under "/tmp" (which is a really poor place for something designed to be a shared identifier for communication between multiple apps)... But, mostly I dislike them because THEY ARE NOT FILES! Just having them exist as a directory entry in the filesystem does not fulfill some Unix utopia idea of "everything is a file"... In order for that to be fulfilled, the things must actually be usable AS FILES... If they were designed such that you could pass one to an otherwise unsuspecting app, which just open()'d it normally, and that magically let that app talk to whoever is listening on the other end of the socket (a la a named pipe), then I'd be all in favor of them... That would be brilliant... But, no, you can't do that... All you can do with a Unix domain socket "file" is to bind() to it or connect() to it... They're not files; they're filesystem representations of unique socket addresses, and that's all... As such, there's no need for them to live in the filesystem at all... (Unless you have special rare needs like those previously mentioned which can only be solved by them having a pathname in the filesystem...)
Review: The Linux Programming Interface Posted Jan 27, 2011 14:14 UTC (Thu) by renox (subscriber, #23785) [Link]
> that if it were holding a TCP port# instead? Do you complain that you can't "rm" listening TCP ports, too?
I had this need in one of our application, to workaround an issue I had to use a small tool which can 'force close' a 'listening TCP ports', having the possibility to 'rm' listening TCP ports would have been much more easy.
|
|||||||||||||