Just to chime in, I had to implement something similar to what Joe suggested to solve the problem. An add queue and a delete queue in addition I had to create a method for poking the select to wake up and cycle through the additions and subtractions. Since most of the additions and subtractions were on either a close or an accept, the poking of the Q was really only need when I wanted to add the APR_POLLOUT event to the select. In my experience adding and removing events happens quite often in all socket programs. It would be extremely useful if this functionality was built into the apr and was thread safe.
Don't the pools use mutexing already, is this platform specific? -----Original Message----- From: Paul Querna [mailto:[EMAIL PROTECTED] Sent: Thursday, September 23, 2004 11:09 AM To: Joe Orton Cc: dev@apr.apache.org Subject: Re: Pollset: Thread Safe & More 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. 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. -Paul Querna © 2004 OpenLink Financial Copyright in this message and any attachments remains with us. It is confidential and may be legally privileged. If this message is not intended for you it must not be read, copied or used by you or disclosed to anyone else. Please advise the sender immediately if you have received this message in error. Although this message and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Open Link Financial, Inc. for any loss or damage in any way arising from its use.
