Thursday, March 15, 2012, 12:39:08 PM, you wrote:
> On 3/15/12 10:58 AM, Alan M. Carroll wrote:
>> Thursday, March 15, 2012, 10:43:34 AM, you wrote:
This can only occur when there is some connection sharing or if someone has
introduced a thread switch in some other processor which trigg
Thursday, March 15, 2012, 9:26:33 AM, you wrote:
> [The lock] is only de-allocated after the close() by which time all
> references to that NetVC should have been dropped by the client.
Yes, I understand. What I do not understand is what actual, specific,
implementation mechanism I can use to ma
On 3/15/12 10:58 AM, Alan M. Carroll wrote:
Thursday, March 15, 2012, 10:43:34 AM, you wrote:
This can only occur when there is some connection sharing or if someone has
introduced a thread switch in some other processor which triggers the OS
connection. AFAIK the OS connection is initiated on
Thursday, March 15, 2012, 10:43:34 AM, you wrote:
>> This can only occur when there is some connection sharing or if someone has
>> introduced a thread switch in some other processor which triggers the OS
>> connection. AFAIK the OS connection is initiated on the thread which has
>> the client co
> Date: Wed, 14 Mar 2012 19:29:43 -0700
> From: jplev...@acm.org
>
> 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 sh
On 3/14/12 8:29 PM, John Plevyak wrote:
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 star
On Thu, Mar 15, 2012 at 7:05 AM, Alan M. Carroll <
a...@network-geographics.com> wrote:
> Wednesday, March 14, 2012, 9:29:43 PM, John Plevyak wrote:
>
> > My view is that this is only one of many failure modes, albeit the most
> > common one.
>
> I disagree because only in the close case is the lo
Wednesday, March 14, 2012, 9:29:43 PM, John Plevyak wrote:
> My view is that this is only one of many failure modes, albeit the most
> common one.
I disagree because only in the close case is the lock itself de-allocated. In
all other cases the locks continue to be valid. So while all the other
awesome!
- Original Message -
> 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 mat
