[zeromq-dev] "thread safe" sockets and ZMQ_FD

[Doron Somech]

Eventually the idea is to create epoll like API (zpoll?) to be used when
polling on multiple sockets (which will create one file descriptor for the
zpoll object) and to stop using the zmq_poll (only relevant for thread safe
sockets).

Example of the API:

void* zmq_zpoll();
int zmq_zpoll_close(void* zpoll);
int zmq_zpoll_add_socket(void* zpoll, void* s, zpoll_event* event);
int zmq_zpoll_remove_socket(void* zpoll, void* s);
int zmq_zpoll_add_fd(void* zpoll, int fd, zpoll_event* event); // for
native file descriptor
int zmq_zpoll_remove_fd(void* zpoll, int fd, zpoll_event* event);
int zmq_zpoll_wait(void* zpoll, int timeout, zpoll_event* event);


On Sun, Feb 22, 2015 at 3:19 PM, Joe McIlvain <joe.eli.mac at gmail.com> wrote:

> I thought one of the major motivations for sharing a socket among threads
> was to avoid the (anti-)pattern of creating a socket for each request in a
> multithreaded environment and worrying about running out of file
> descriptors.  It sounds like this new strategy would avoid allocations of
> more zmq socket structures, but still carry the same risks of file
> descriptor sprawl and possible exhaustion.  Also if a signaller is created
> on each call to zmq_poll, what is the plan for how these FDs might be
> "garbage collected" so that you don't run out of FDs just from calling
> zmq_poll too many times (even from the same thread)?
>
> On Sat, Feb 21, 2015 at 9:27 AM, Doron Somech <somdoron at gmail.com> wrote:
>
>> The one need to dispose it. My plan was to support zmq_poll by create
>> signaler on each call.
>> On Feb 21, 2015 6:21 PM, "Thomas Rodgers" <rodgert at twrodgers.com> wrote:
>>
>>> I will hold off until you've fleshed out those details, but it sounds
>>> like the API for getting the signaling FD will be different from what
>>> everything else uses currently, which means there will be a class of socket
>>> types that I will need to special case to support in my bindings. Is there
>>> anyway to just make that API get_sockopt() for ZMQ_FD but make the FD
>>> returned the 'new' signaling one?
>>>
>>> On Saturday, February 21, 2015, Doron Somech <somdoron at gmail.com> wrote:
>>>
>>>> Currently the thread safe sockets doesn't support polling on multiple
>>>> sockets as stated in the PR:
>>>>
>>>> https://github.com/zeromq/libzmq/pull/1349
>>>>
>>>> I'm planning to solve that by epoll like API where you create a poll
>>>> and then add sockets to it. The poll type will create a file descriptor
>>>> that will be added to each of the associated thread safe sockets.
>>>>
>>>> The mailbox_safe type already (
>>>> https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp)
>>>> have a method called add signaler which is actually a file descriptor.
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Feb 21, 2015 at 5:27 PM, Thomas Rodgers <rodgert at twrodgers.com>
>>>> wrote:
>>>>
>>>>> It looks like the recently added code for supporting thread safe
>>>>> sockets does not support returning the signalling FD for a socket that is
>>>>> marked "thread safe". How would these socket types be used in a polling
>>>>> reactor then?
>>>>>
>>>>> _______________________________________________
>>>>> zeromq-dev mailing list
>>>>> zeromq-dev at lists.zeromq.org
>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150222/529cc92a/attachment.htm>