Author christian.heimes
Recipients christian.heimes, therve
Date 2007-12-19.10:50:49
SpamBayes Score 0.0032293
Marked as misclassified No
Message-id <1198061449.48.0.88362713326.issue1657@psf.upfronthosting.co.za>
In-reply-to
Content
> For this patch, I don't see the benefit of putting it in the select
> module, instead of a separate module. Is there a specific reason?

There is at least one, but probably several other modules named "epoll"
or "_epoll" in the wild. These modules implement an epoll interface with
Pyrex, ctypes or C. All of them have a slightly different API. I don't
want to break 3rd party software.

The select module already contains an interface to select and poll. IMO
it's the best place.

> Looking at the code, I don't have many remarks. pyepoll_new may leak
> if epoll_create fails. I think that allowing threading around
> epoll_ctl is useless, but I may be wrong.

Thanks, I've fixed the problem in pyepoll_new.

The Linux kernel protects every call to epoll_ctl with a mutex. It
*could* block and therefor I'm allowing threads around the epoll_ctl() call.
History
Date User Action Args
2007-12-19 10:50:49christian.heimessetspambayes_score: 0.0032293 -> 0.0032293
recipients: + christian.heimes, therve
2007-12-19 10:50:49christian.heimessetspambayes_score: 0.0032293 -> 0.0032293
messageid: <1198061449.48.0.88362713326.issue1657@psf.upfronthosting.co.za>
2007-12-19 10:50:49christian.heimeslinkissue1657 messages
2007-12-19 10:50:49christian.heimescreate