Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of justin.erenkrantz@gmail.com
 designates 209.85.200.168 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=s8jThZOJNArF3rRELFqKby/IBlQf36AlkFMjjF0DXbQNiSb+ka5Aj+Z+mny7jypdKM
         YoIqv8+O/7CpBYKIIZ/xA0OyEQ9lIe37qBY61SIQptWF4P6G1xXe/Ew4AXuUxGn/7c4U
         6c/U9N6OxDOj5rsUN7GUWMmIdTOEGg8kf1NPA=
MIME-Version: 1.0
Sender: justin.erenkrantz@gmail.com
In-Reply-To: <4239a4320907062220k21987b38uebbd3e7b1c7f0f37@mail.gmail.com>
References: <4239a4320907062220k21987b38uebbd3e7b1c7f0f37@mail.gmail.com>
Date: Mon, 6 Jul 2009 22:50:45 -0700
Message-ID: <5c902b9e0907062250o4b566ef8yffb293ca0f9311b9@mail.gmail.com>
Subject: Re: Events, Destruction and Locking
From: Justin Erenkrantz <justin@erenkrantz.com>
To: dev@httpd.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 6, 2009 at 10:20 PM, Paul Querna<paul@querna.org> wrote:
> I am looking for an alternative that doesn't expose all this crazyness
> of when to free, destruct, or lock things. =A0The best idea I can come
> up with is for each Connection, it would become 'semi-sticky' to a
> single thread. =A0Meaning each worker thread would have its own queue of
> upcoming events to process, and all events for connection X would sit
> on the same 'queue'. =A0This would prevent two threads waiting for
> destruction, and other cases of a single connection's mutex locking up
> all your works, essentially providing basic fault isolation.
>
> These queues could be mutable, and you could 'move' a connection
> between queues, but you would always take all of its events and
> triggers, and move them together to a different queue.
>
> Does the 'connection event queue' idea make sense?

I think I see where you're going with this...being so dependent upon
mutexes seems...like going into a jungle full of guerillas armed with
only a dull kitchen knife.

So, a connection gets assigned to a 'thread' - but it has only two
states: running or waiting for a network event.  The critical part is
that the thread *never* blocks on network traffic...all the 'network
event' thread does is detect "yup, ready to go" and throws it back to
that 'assigned' thread to process the event.  Seems trivial enough to
do with a serf-centric system.  =3D)

> I'm not sure I'm expressing the idea fully over email.... but I'll be
> at OSCON in a few weeks if anyone wants beer :)

I'll take you up on the beer and we can mull it over...  -- justin