On Thu, Mar 26, 2009 at 8:24 PM, <Daniel.Pocock@barclayscapital.com> wrote:
Excellent point - I should have checked for a return code, there are a
> APR_POLLSET_THREADSAFE isn't supported with all
> implementations. I expect that apr_pollset_create() is
> returning APR_ENOTIMPL, and the crash is due to an
> uninitialized pollset.
few cases like this in Ganglia where the return codes are ignored.
I've now added this check, and apr_pollset_create is returning
The seg fault only occurs after the first socket is added to the
pollset, maybe there is another place where return codes are ignored?
Hmmm... I see that poll() or select()-based pollset implementations return APR_ENOTIMPL when APR_POLLSET_THREADSAFE is spectified, and I don't know how Windows could use anything else under the covers ;)
Ganglia doesn't need it normally, it is just a single thread. The seg
> Just curious: Does Ganglia modify the pollset on a separate
> thread than the poll (thus needing APR_POLLSET_THREADSAFE),
> and if so why doesn't it already specify
> APR_POLLSET_THREADSAFE *and* check the apr_pollset_create()
> return code? And if it doesn't need it, what do you expect
> to gain by adding it?
fault occurs during the single threaded initialisation phase where
sockets are created.
However, I am taking advantage of Ganglia's new module API, and some of
my modules start threads. One of them, which works on Linux and
Solaris, uses libcurl from another thread, and I was getting crashes
until I added APR_POLLSET_THREADSAFE. Now I want to run the same code
Weird... I would expect that APR_POLLSET_THREADSAFE is only needed with use of the SAME pollset on multiple threads, and using libcurl from another thread wouldn't affect Ganglia's use of its own pollset.
I have tested this with apr-1.2.7 under Cygwin now, it also has the same
Did apr-1.2.x even know about APR_POLLSET_THREADSAFE?