[Dovecot] [PATCH] pass struct io * to io_loop_handle_add()/io_loop_handle_remove()
Hello,
currently I'm working on new ioloop handler which uses epoll(4) API introduced in Linux kernel 2.6. In this API each fd added to fd set by epoll_ctl system call can be accompanied with user supplied data (integer or void pointer). epoll_wait syscall reports arrived events as an array of structures containing event mask and user data.
Attached patch replaces fd and condition parameters passed to io_loop_handle_add() with struct io pointer. Now io_loop_handle_add() can pass this pointer as user data to epoll_ctl syscall and when event arrives we will have corresponding io structure pointer for free withiot traversing possibly long ioloop->ios list.
Please take a look.
Best regards.
-- Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net
On 23.8.2004, at 15:50, Andrey Panin wrote:
Attached patch replaces fd and condition parameters passed to io_loop_handle_add() with struct io pointer. Now io_loop_handle_add() can pass this pointer as user data to epoll_ctl syscall and when event arrives we will have corresponding io structure pointer for free withiot traversing possibly long ioloop->ios list.
Committed, but you'd also have to change the way io_destroy() works. I guess it could be simply changed to use reference counting instead of the delayed destroying. Hmm. Looks like ioloop code could use several optimizations..
On 236, 08 23, 2004 at 05:04:01PM +0300, Timo Sirainen wrote:
On 23.8.2004, at 15:50, Andrey Panin wrote:
Attached patch replaces fd and condition parameters passed to io_loop_handle_add() with struct io pointer. Now io_loop_handle_add() can pass this pointer as user data to epoll_ctl syscall and when event arrives we will have corresponding io structure pointer for free without traversing possibly long ioloop->ios list.
Committed, but you'd also have to change the way io_destroy() works.
I'm looking at it already.
I guess it could be simply changed to use reference counting instead of the delayed destroying. Hmm. Looks like ioloop code could use several optimizations..
Reference counting... Hmm, I thinked about replacing ioloop->ios single linked list with doubly linked list, it should make removal of io entries easy and loop in the io_add() function can be removed too.
-- Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net
On 24.8.2004, at 14:05, Andrey Panin wrote:
I guess it could be simply changed to use reference counting instead of the delayed destroying. Hmm. Looks like ioloop code could use several optimizations..
Reference counting... Hmm, I thinked about replacing ioloop->ios single linked list with doubly linked list, it should make removal of io entries easy and loop in the io_add() function can be removed too.
Actually now I remember the real problem why I did delayed destroying. Because io_remove() may remove any one of the io structures and it can be called inside the io callback, it wasn't possible to know what the next valid io structure would be because the current and next ones might have been freed already.
Anyway, simple to fix. Keep the next io pointer in ioloop struct and if io_remove() wants to free it, it updates the next pointer.
Doubly linked lists would be good too.
On 237, 08 24, 2004 at 07:58:05PM +0300, Timo Sirainen wrote:
On 24.8.2004, at 14:05, Andrey Panin wrote:
I guess it could be simply changed to use reference counting instead of the delayed destroying. Hmm. Looks like ioloop code could use several optimizations..
Reference counting... Hmm, I thinked about replacing ioloop->ios single linked list with doubly linked list, it should make removal of io entries easy and loop in the io_add() function can be removed too.
Actually now I remember the real problem why I did delayed destroying. Because io_remove() may remove any one of the io structures and it can be called inside the io callback, it wasn't possible to know what the next valid io structure would be because the current and next ones might have been freed already.
Anyway, simple to fix. Keep the next io pointer in ioloop struct and if io_remove() wants to free it, it updates the next pointer.
Doubly linked lists would be good too.
Ok. Another question: epoll_wait() reports events in order of arrival and so io callbacks will be called in this order, not in order of ioloop->ios list. Is this difference significant ?
-- Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net
participants (2)
-
Andrey Panin
-
Timo Sirainen