httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: [PATCH] Threaded MPM and unserialized accept
Date Mon, 16 Jul 2001 20:18:57 GMT
On Mon, Jul 16, 2001 at 03:42:21PM -0400, Greg Ames wrote:
> If you don't have all the idle workers waiting on accept on a platform
> with S_L_U_A, it seems sub-optimal due to extra syscalls in the main
> path.

Correct.  This solution bugs me, but I can't come up with a way to
resolve this problem given the current design of the threaded MPM.  
Ryan has stated that this patch brings us to the original design
that he and Manoj implemented with apache-apr.

> I'll take a closer look at your patch, now that I understand what you're
> trying to fix.  But if you're mutexing the accepts within a process for
> the S_L_U_A case, I'd really like to find an alternative design.  Like
> hitting the threads with more dummy connects when the process needs to
> go away, for example.

You'd have to do max_workers * threads_per_process (names are probably
wrong) connects.  That's just as bad.  =)  And, that doesn't even
guarantee you to wake all of the threads - it's now dependent on the
ordering of the accept calls which may be LIFO or FIFO.  (Unless you
were to overwhelm the server with dummy connects - rather than doing
them in serial - but now you've caused a DoS.)

I think the POD works fine for a multi-process server, but not for a
multi-process/multi-thread server.  There is a major disconnect
happening here.  I think this calls for some other restart mechanism 
for multi-process/multi-thread MPMs.

> We still don't have a good way to kill threads that are busy serving
> .iso's when a non-graceful restart or shutdown happens.

Correct.  But, it is a slightly different problem.  The thread is
active and as soon as it finishes, it will quit.  The converse 
problem is that the threads are idle and will never see the w_m_e 
value.  -- justin

View raw message