Cliff Woolley wrote:
>On Sat, 31 Aug 2002, Brian Pane wrote:
>
>
>
>> * The bucket allocator alloc/free code isn't
>> thread-safe, so bad things will happen if the
>> writer thread tries to free a bucket (that's
>> just been written to the client) at the same
>> time that a worker thread is allocating a new
>> bucket for a subsequent request on the same
>> connection.
>>
>>
>
>We designed with this in mind... basically what's supposed to happen is
>that rather than having a bucket allocator per thread you have a group of
>available bucket allocators, and you assign one to each new connection.
>Since each connection will be processed by at most one thread at a time,
>you're safe. When the connection is closed, the allocator is placed back
>into the list of available allocators for reuse on future connections.
>
>
I don't think we can count on the assumption that each conn will
only be processed by one thread at a time. For example, this race
condition can happen on a keepalive connection with pipelined
requests:
1. Listener thread accepts connection, obtains a bucket
allocator, assigns the allocator to the connection.
2. Worker thread reads the first request from the connection.
It's a simple file request, so the worker thread creates
a 3-bucket brigade (response header, file bucket, EOS)
and sends it to the writer thead.
3. Writer thread starts the sendfile/sendfilev
4. Worker thread reads the second response from the connection.
This one is a CGI or proxy request that takes a long time
and results in a long stream of buckets.
5. Meanwhile, the sendfile call completes. The writer thread
deletes the file bucket...at the same time that the worker
thread is allocating another heap bucket.
6. Segfault, etc, etc.
In fact, this could even happen without keepalives, if a long-running
proxy request is still producing new buckets for a response while the
writer thread is handling buckets earlier in the same response.
Brian
