ZeroMq IRC Log

Saturday June 26, 2010

[Time] Name	Message
[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!