On Thu, Sep 23, 2004 at 09:08:59AM -0600, Paul Querna wrote: > On Thu, 2004-09-23 at 11:38 +0100, Joe Orton wrote: > > So I'm worried this patch is really solving the problem in the wrong > > place. The thing you are exporting here in the APR API, "is the > > apr_pollset_* interface thread-safe in _add and _remove", seems really > > horrible. Either an API is thread-safe, or it isn't. Making that a > > *per-platform* flag seems like really bad design. > > I agree with your conclusion here. It isn't a good design to have > platform specific properties like thread safety.
I suppose it wouldn't be so bad if this was enabled as flag passed to apr_pollset_create (which already has a convenient flags parameter, kudos to whomever for the forward thinking there). apr_pollset_create(,,,APR_POLLSET_THREADSAFE) which gives ENOTIMPL for non-kqueue/epoll implementations, and the mutex locking is only used if it *is* specified. > Part of my goal was to avoid using KQueue/EPoll directly in the Event > MPM, and to keep it using the APR Generic Functions. I think that I > will just make an ap_ex_pollset_* set of functions to wrap EPoll/KQueue > and include them directly in the Event MPM. It does seem a shame to duplicate so much of this stuff... joe
