Hi all,
There's been a few murmurs on IRC about getting a 3.2 release out. What do
people think about this? Have we accumulated enough improvements over 3.0 for a
new release to be interesting? Are we stable enough that a quality 3.2 could be
released within a couple of months?
J
This looks to be superior to that patch, so I would be for replacing that.
I still see this as a quite complicated bandaid, but if it makes things
better in the short term, I am not opposed.
john
On Wed, Mar 14, 2012 at 11:44 AM, Alan M. Carroll <
a...@network-geographics.com> wrote:
> One thin
On Wed, Mar 14, 2012 at 8:22 AM, Alan M. Carroll <
a...@network-geographics.com> wrote:
>
> > There is, however, one situation where this simple and safe order of
> events
> > is not followed. That is connection sharing to origin servers. Here the
> > situations starts the same, but when the cli
I remember the commit had already reverted and I said the rescheduling
patch have problems in irc.
On Wed, 2012-03-14 at 13:44 -0500, Alan M. Carroll wrote:
> One thing that should be noted is that, regardless of whether this patch is a
> permanent fix, I think it is clearly superior to the curr
Wednesday, March 14, 2012, 10:57:17 AM, you wrote:
> according to your example timeline, can we tell that there is a path
> that httpSM dereference vc after it call vc->do_io_close?
For thread B, the mutex->acquire() dereferences the VC pointer to get the mutex
object. If you want a fuller chai
On Wed, 2012-03-14 at 10:22 -0500, Alan M. Carroll wrote:
> Tuesday, March 13, 2012, 11:46:15 PM, you wrote:
>
> > Here are my comments for what they are worth.
>
> > First, let me detail the issue this is trying to address.
>
> > The way that most clients work with VCs is via and Processor::ope
Tuesday, March 13, 2012, 11:46:15 PM, you wrote:
> Here are my comments for what they are worth.
> First, let me detail the issue this is trying to address.
> The way that most clients work with VCs is via and Processor::open_
> which calls back with and OPEN event at which point they set VI
On 14/03/2012 06:12, James Peach wrote:
> Hi all,
>
> I just committed support for the Server Name Indication TLS extension to
> trunk. There's no additional configuration necessary. When we load any
> certificate, we will automatically parse the subject CN and all the alternate
> DNS names and
I have not read this patch carefully so I have no idea that the patch
solved the problem or not. I just have two question:
1) do we find the cause of the crash? (how to trigger the crash, in what
situation)
2) is it worth using smart pointer to prevent the crash? (maintain the
design principle of
