Re: [zeromq-dev] adding other file descriptors to zmq::pollitem_t array
Hello,
Yes you can poll on native file descriptor without problem.
From the documentation (http://api.zeromq.org/4-1:zmq-poll): ZMQ_POLLIN
"For ØMQ sockets, at least one message may be received from the socket
without blocking. For standard sockets this is equivalent to the
POLLIN flag of the poll() system call and generally means that at
least one byte of data may be read from fd without blocking."
On Tue, Mar 3, 2015 at 11:15 PM, André Caron wrote:
> AFAICT, zmq_poll supports any native fd by design. What fds are accepted is
> system dependant. For example, on Windows, it only accepts sockets (but not
> regular files like stdin). On other platforms, YMMV I guess.
>
> Cheers,
>
> André
>
> On Tue, Mar 3, 2015 at 4:51 PM, alex. wrote:
>>
>> I am building a threaded file monitoring tool using zmq and inotify. I
>> discovered that I will have a nasty block when I want to end a thread
>> that is currently blocking while watching a file.
>>
>> Since I am solving similar problems of threads waiting for zmq
>> messages with a double polling on two separate endpoints, one being
>> the actual endpoint and the other being a custom SIGTERM-message
>> broadcast from the main thread, I was wondering if I could do the same
>> here. As I want to solve all thread synchronisation problems using
>> such polling and zmq messages (stearing clear of stuff like mutexes
>> and signals), this seems to be a good go.
>>
>> I dived into the code and realized that the zmq_poll() is basically a
>> wrapper for the system's poll() function, which is also the suggested
>> polling method for inotify. I went ahead and simply added inotify's
>> file descriptor (fd) as an item to my zmq::pollitem_t array (passing a
>> 0 as the socket):
>>
>> { 0, fd, ZMQ_POLLIN, 0 }
>>
>> This seems to work quite well actually! Now I wanted to ask if this is
>> okay for production use. I even let the ZMQ_POLLIN in, as I am not
>> sure if zeromq's polling will handle the system's POLLIN well enough,
>> but the inverse may just as well be true?
>>
>> So is it advisable to just shove the fd of inotify into zmq's polling
>> function?
>>
>> Thanks!
>> alex.
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
--
Kapp Arnaud - Xaqq
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] adding other file descriptors to zmq::pollitem_t array
AFAICT, zmq_poll supports any native fd by design. What fds are accepted
is system dependant. For example, on Windows, it only accepts sockets (but
not regular files like stdin). On other platforms, YMMV I guess.
Cheers,
André
On Tue, Mar 3, 2015 at 4:51 PM, alex. wrote:
> I am building a threaded file monitoring tool using zmq and inotify. I
> discovered that I will have a nasty block when I want to end a thread
> that is currently blocking while watching a file.
>
> Since I am solving similar problems of threads waiting for zmq
> messages with a double polling on two separate endpoints, one being
> the actual endpoint and the other being a custom SIGTERM-message
> broadcast from the main thread, I was wondering if I could do the same
> here. As I want to solve all thread synchronisation problems using
> such polling and zmq messages (stearing clear of stuff like mutexes
> and signals), this seems to be a good go.
>
> I dived into the code and realized that the zmq_poll() is basically a
> wrapper for the system's poll() function, which is also the suggested
> polling method for inotify. I went ahead and simply added inotify's
> file descriptor (fd) as an item to my zmq::pollitem_t array (passing a
> 0 as the socket):
>
> { 0, fd, ZMQ_POLLIN, 0 }
>
> This seems to work quite well actually! Now I wanted to ask if this is
> okay for production use. I even let the ZMQ_POLLIN in, as I am not
> sure if zeromq's polling will handle the system's POLLIN well enough,
> but the inverse may just as well be true?
>
> So is it advisable to just shove the fd of inotify into zmq's polling
> function?
>
> Thanks!
> alex.
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] adding other file descriptors to zmq::pollitem_t array
I am building a threaded file monitoring tool using zmq and inotify. I
discovered that I will have a nasty block when I want to end a thread
that is currently blocking while watching a file.
Since I am solving similar problems of threads waiting for zmq
messages with a double polling on two separate endpoints, one being
the actual endpoint and the other being a custom SIGTERM-message
broadcast from the main thread, I was wondering if I could do the same
here. As I want to solve all thread synchronisation problems using
such polling and zmq messages (stearing clear of stuff like mutexes
and signals), this seems to be a good go.
I dived into the code and realized that the zmq_poll() is basically a
wrapper for the system's poll() function, which is also the suggested
polling method for inotify. I went ahead and simply added inotify's
file descriptor (fd) as an item to my zmq::pollitem_t array (passing a
0 as the socket):
{ 0, fd, ZMQ_POLLIN, 0 }
This seems to work quite well actually! Now I wanted to ask if this is
okay for production use. I even let the ZMQ_POLLIN in, as I am not
sure if zeromq's polling will handle the system's POLLIN well enough,
but the inverse may just as well be true?
So is it advisable to just shove the fd of inotify into zmq's polling
function?
Thanks!
alex.
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
