gregoryyoung1 at gmail.com
Thu Dec 6 08:08:21 UTC 2012
push coming. I learned the lesson the hard way long ago to never ever hold
a lock when issuing a call to unknown code. This ended up biting us as some
work was being done on the callback and the accepting of a new request was
being blocked :( I might have 2-3 more as I try to figure out the
bottlenecks in our http stuff so will try to get them together into one
On Thu, Dec 6, 2012 at 3:43 AM, Andres G. Aragoneses <knocte at gmail.com>wrote:
> Hey Rodrigo, by looking at https://github.com/mono/mono/**commit/**
> 04c641a21c2ba92c3262948ed1b68e**b22c643b11<https://github.com/mono/mono/commit/04c641a21c2ba92c3262948ed1b68eb22c643b11>as you point out, it would make sense to find the call to
> GetContextFromQueue() inside the lock, but maybe ares.Complete() can be
> outside for better performance? (And then inside again when adding it to
> the wait_queue again.) Which is maybe what Greg meant.
> On 05/12/12 14:05, Rodrigo Kumpera wrote:
>> Did you look at the git history for those changes to see why those
>> changes have been made?
>> 04c641a21c2ba92c3262948ed1b68e**b22c643b11 seens relevant.
>> On Wed, Dec 5, 2012 at 8:52 AM, Greg Young <gregoryyoung1 at gmail.com
>> <mailto:gregoryyoung1 at gmail.**com <gregoryyoung1 at gmail.com>>> wrote:
>> CheckDisposed ();
>> if (!listening)
>> throw new InvalidOperationException ("Please, call Start before
>> using this method.");
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.**com <Mono-devel-list at lists.ximian.com>
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.**com <Mono-devel-list at lists.ximian.com>
Le doute n'est pas une condition agréable, mais la certitude est absurde.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list