Saturday June 26, 2010

[Time] NameMessage
[01:24] zedas sustrik: question about zmq_poll: it uses epoll if available right? is there more you need to do?
[01:29] zedas sustrik: ahhh, zmq_poll system checks the rlimit and restricts available open fds to that. i'll look at doing the same.
[06:23] sustrik zedas: hi
[06:23] sustrik what code are you looking at?
[06:23] sustrik at the moment zmq_poll translates to standard poll
[06:24] sustrik calling epoll makes not sense unless 0mq's zmq_poll API changes in the corresponding way
[06:25] sustrik (registering fds separated from polling etc.)
[06:35] zedas sustrik: i was looking at the poll.cpp and others.
[06:35] zedas so i was under the impression that zmq_poll abstracts poll/epoll/kqueue.
[06:35] zedas at least that's how the docs read.
[06:35] zedas that not true?
[06:35] sustrik the polling is done at 2 places
[06:35] sustrik I/O threads from the thread pool are polling using epoll/whatever
[06:36] sustrik meaning that if one 0MQ socket manages 100,000 TCP connections
[06:36] sustrik these are looked for by epoll-based mechanism (on Linux at least)
[06:36] sustrik then there's user polling (zmq_poll)
[06:36] sustrik this at the moment translates to POSIX poll
[06:37] sustrik however, i wouldn't expect anyone to use large amount of 0mq sockets
[06:37] sustrik the only problem is if user wants to poll on couple of 0mq sockets + large amount of system sockets
[06:37] sustrik is that your case?
[06:39] zedas probably. it's in mongrel2
[06:39] zedas it craps out at 1024 sockets, which i haven't investigated yet, but even poll should handle that
[06:40] zedas so, if you have these abstractions on epoll, kqueue, devpoll, and poll, why not have zmq_poll use them?
[06:40] sustrik epoll reuires different API
[06:40] sustrik otherwise it's of no use
[06:41] sustrik the performance boost is related to registering the fds separately from polling as such
[06:42] sustrik current zmq_poll is only a dumb copy of POSIX poll
[06:42] sustrik there have been some discussion on alternate API but it never got into implementation phase
[06:43] zedas well, plenty of libraries have given a consistent api to all the different event mechanisms
[06:44] zedas it's not like this is anything new, even if they have different apis.
[06:44] zedas looking at the code, it looks like you have the basis for the abstraction, probably just needs to be pulled into zmq_poll and used
[06:44] zedas i may look at doing that in the near future.
[06:44] sustrik that would be nice
[06:44] zedas that and get rid of this #ifdef, the loop that seems to no be needed, etc.
[06:45] sustrik what loop?
[06:46] zedas the double nested while(true)
[06:46] zedas haven't seen a poll loop implemented that way, so i'm assuming there's something odd there
[06:47] zedas yeah i think i could clean this up and make it use the abstractions you've got
[06:47] zedas or at least make it use epoll if that's available.
[06:48] zedas hehe hell i could just write a zmq_epoll and zmq_kqueue and leave it to the developer :-)
[06:48] zedas but that'd be me, so i want zmq_poll to do whatever works best
[06:48] sustrik yes, that's the option
[06:48] sustrik the obvious problem is that there's no POSIX standard fro epoll-style polling
[06:49] sustrik kqueue seems to be most neat, but still it's hard to decide on actual API
[06:49] sustrik try posting your new API to the mailing list first to see what others have to say about it
[06:51] zedas i'll give it a shot when i get to that part. right after i find out why it craps out at 1024 fds
[06:52] sustrik ack
[06:52] zedas with poll it shouldn't do that but it does. which means people will perf test it and then bitch that i'm using select
[06:52] zedas well not an issue now, just gonna drive me crazy later :-)
[06:53] sustrik ok, good luck for now
[06:55] zedas yeah so far it's working great.
[06:55] zedas i've got the tasks working flawlessly with sockets or 0mq
[06:58] sustrik glad to hear that!