| |||||||||||||
EPOLL_CTL_DISABLE, epoll, and API designEPOLL_CTL_DISABLE, epoll, and API designPosted Oct 23, 2012 23:04 UTC (Tue) by nybble41 (subscriber, #55106)In reply to: EPOLL_CTL_DISABLE, epoll, and API design by dlang Parent article: EPOLL_CTL_DISABLE, epoll, and API design
In cases like this one, where the problem is just unused parameters which weren't checked, it seems like a simple enough thing to fix. Just create a new API for new applications that follow the rules, and make the old one forward to the new one after masking out the unused parts. For example, epoll_ctl(epfd, op, fd, event) could call epoll_ctl_v2(epfd, op, fd, NULL), ignoring event; anything that wants to use the last parameter would call epoll_ctl_v2 directly. The same principle would work for bitfields. The new API could easily be made automatic for new programs through versioned library symbols.
However, I agree that in general maintaining multiple API versions, where the old one is not a simple subset of the new one, is not likely to go well.
(Log in to post comments)
EPOLL_CTL_DISABLE, epoll, and API design Posted Oct 25, 2012 9:42 UTC (Thu) by dgm (subscriber, #49227) [Link]
> However, I agree that in general maintaining multiple API versions, where the old one is not a simple subset of the new one, is not likely to go well.
For that reason we should be putting much more effort into API design. In fact, tacking into account that API _will_ outlive its implementation (maybe several of them), most of the effort should be towards getting the API right.
|
|||||||||||||