Re: [Fwd: 1.2b20-1: Async IO fixes & optimizations]

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii

> The 1 second timeout was fixed in a slightly different way:
> * Threads send a SIGCONT signal to the main thread, which breaks the
> select() call (EINTR).

        Eeps. Sending signals is a seriously slow way to do communication.
Sure it'll break the select loop, but each finishing thread may incur a lot
of system overhead for signal processing. I wouldn't recommend this
approach.

> * A slightly lowered timeout (1/4 second), in case we miss the signal.
> * Two "hints": one telling the threads that the main loop is blocked on
> select and one telling the main loop that a thread has finished. The
> hints are used to avoid uneccesary signals/blocking selects.

        I wanted to avoid any knowledge of what the thread library was doing
from the main part of squid in order to prevent data sharing. I see that you
broke this by introducing external data into the low-level thread library.

> The "spin"-situation was fixed by properly protecting the condition
> variable with a mutex (the documented way to use pthread_cond_wait).
> Non-blocking main thread is achived by using the non-blocking
> pthread_mutex_trylock instead of _lock.

        Sigh. I wanted to avoid all use of locks to prevent any form of
resource waiting. The method I used did this. I even had a working version
that did away with pthread_cond_wait() at the expense of more FD's. Sure
pthread_cond_wait() has implicit internal locks, but I was happy for it to
handle that side of the business itself.

> If some platform does not support _mutex_trylock, it could be replaced
> with a blocking _mutex_lock. The penalty is a block for 2 context
> switches to let the thread enter pthread_cond_wait.
>
> The I/O thread holds the mutex permanently, except during
> pthread_cond_wait. The main thread holds the mutex when it knows that
> the I/O thread is idle.
>
> The "Solaris hack" is completely removed. Instead the thread side code
> simply reads
>
> thread_loop()
> {
> pthread_mutex_lock(&threadp->mutex)
> for(;;) {
> while (threadp->state != _THREAD_BUSY) {
> threadp->state = _THREAD_WAITING;
> pthread_cond_wait(&(threadp->cond));
> }
> request = threadp->req;
> [process request]
> }
> pthread_mutex_unlock(&threadp->mutex);
> }
>
> Remember that the mutex is held at all times, properly protecting any
> updates/reads in the threadp structure.

        There wasn't any race condition to begin with. There never was the
situation where the child could read corrupted half-written data.

        Stew.

-- 
Stewart Forster (Snr. Development Engineer)
connect.com.au pty ltd, Level 9, 114 Albert Rd, Sth Melbourne, VIC 3205, Aust.
Email: slf@connect.com.au   Phone: +61 3 9251-3684   Fax: +61 3 9251-3666
--MimeMultipartBoundary--