[nanomsg] Re: On the use of small integers instead of pointers to identify "sockets"
- From: Nico Williams <nico@xxxxxxxxxxxxxxxx>
- To: Martin Sustrik <sustrik@xxxxxxxxxx>
- Date: Thu, 5 Sep 2013 03:13:24 -0500
On Thu, Sep 5, 2013 at 12:03 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> On 04/09/13 17:50, Nico Williams wrote:
>
>> But surely nanomsg fd numbers can't be passed to POSIX system calls and
>> library functions!
>
> No. You can't implement that in user space. POSIX doesn't allow for that
> kind of thing. True file descriptors can be implemented only in the kernel
> space.
Well... You could use interposition on Linux and Solaris type OSes.
I'm not advocating that (and I wouldn't; it's neither portable nor
reliable). And you could make sure that any fd returned by nanomsg
has a corresponding /dev/null or similar fd just to protect against
accidental use of nanomsg fds where they don't belong.
> However, I've made a patch for Linux kernel that would fix that and allow
> for implementing true fds in the user space. Unfortunately, I don't have
> enough time and morale to push the patch to the mainline.
Ah! Now I understand. If kernel support via existing POSIX
interfaces is a goal, then your design makes perfect sense. I was
trying to tease this out.
>> Or did I miss something? Perhaps you're just trying to
>> match POSIX system call prototypes [for some reason that I missed]?
>
> Yes. The goal is not to force developers to memorise two slightly different
> sets of APIs. ZeroMQ have diverged that way lately -- the API is kind od
> socket-like, but there's a lot of differences as well. If you are working
> with both APIs you have to do a lot of mental switching which is not very
> helpful.
I don't see much value in that, particularly when the actual numeric
fd values are irrelevant. But the reason you give above is
sufficient.
>>> Btw, one minor, but nice feature of ints as socket handles is that you
>>> can close a socket, then try to use it and get EBADF error. In ZeroMQ,
>>> where I've used pointers as handles, your program just crashes.
>>
>> Er, yes, but since usually the next fd allocated is the lowest non-
>> negative number not currently in use... you could end up (particularly
>> in threaded programs, but not only) writing to the wrong fd. The same
>> could happen if you used pointers, of course, but the point is that bugs
>> are bugs, and [likely] crashing is better than [possible] silent
>> corruption.
>
> True. Both ways are deficient. I guess matter of personal preference in the
> end.
If it were just personal preference then I know mine. But aiming for
true kernel support for nanomsg makes this not a matter of personal
preference. If you didn't want that then I think the alternative is
better because it involves less code, but that's not relevant now.
Case closed.
Thanks for your time!
Nico
--
Other related posts:
