On 22/05/13 18:20, Kai Krueger wrote:
On 05/22/2013 11:04 AM, Tom Hughes wrote:
So if a new child is started, and multiple requests arrive more or
less simultaneously to different threads in that process, then they
will both try and allocate the stores array which means they will both
be trying to manipulate the memory pool at the same time.
>
The apache routines to manipulate memory pools should be thread safe, so
that part should be fine.
That's not what the interwebs are telling me - do you have some
documentation for that claim? Only I'm finding quotes like "Pools are
explicitly thread unsafe".
That's why you have things like per-request pools - so that you can do
allocations in request context without locking overheads as well as so
you can clean up easily.
It does look like it is possible that multiple processes can allocate a
new storage array simultaneously, but that should "only" lead to memory
leak, rather than crashes. In that race, simply one of the threads wins
and gets to set the stores array and the other allocated arrays go
unused. As all allocations are equivalent, it shouldn't matter which wins.
That race should be fixable, by simply adding an explicit lock after the
stores==null check. As this only happens at process / thread
initialisation and all operations are fast, the performance impact of
that should be negligible.
Can the stores array not just be allocated in the child_init hook?
That way it is only the apr_pool_userdata_get call that you are relying
on to be thread safe - no idea if it is, but at it is reading things it
is more likely to be.
Tom
--
Tom Hughes ([email protected])
http://compton.nu/
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
