[Mono-dev] TCP 3.0.1/2
gregoryyoung1 at gmail.com
Wed Nov 28 13:43:09 UTC 2012
That reverse commit also breaks TCP for anyone who uses it.
Without the path that was there (and I believe another in objectpool.c
that was pushed a while ago) what happens is async calls never receive
callbacks under load. Eg Begin->No End.
We had pushed some code to the list a while ago that reliably
reproduced this behaviour.
On Wed, Nov 28, 2012 at 3:39 PM, Rodrigo Kumpera <kumpera at gmail.com> wrote:
> Please point us to the relevant patches that you believe are missing from
> 3.0 and I'll review them.
> In the meanwhile, here's the commit that reverted one of your changes due to
> Locking should be done on the backend not on the frontend.
> commit 47dd377f8587b466475ac5a6cf548f49b9394d0d
> Author: Rodrigo Kumpera <kumpera at gmail.com>
> Date: Thu Nov 1 17:43:25 2012 -0400
> Revert "Merge pull request #464 from gregoryyoung/master"
> This commit causes deadlock in the tpool backend in the following way:
> thread 1:
> socket_io_add locks io_lock
> tp_poll_modify waits on new_sem
> thread 2:
> tp_poll_wait tries to lock io_lock
> tp_poll_wait is the responsible to post to new_sem, which it can't do
> since it's
> blocked on io_lock, held by a thread waiting on new_sem.
> This reverts commit 11286da0ac2e2bab7b2d8ab04b9f6a4da4e12131, reversing
> On Wed, Nov 28, 2012 at 1:23 AM, Greg Young <gregoryyoung1 at gmail.com> wrote:
>> I would be curious in talking a bit more about this because without it
>> TCP does not work reliably.
>> btw: having run billions of calls through TCP under load we have never
>> seen a deadlock on it. Could you describe the deadlock scenario?
>> On Tue, Nov 27, 2012 at 9:37 PM, Rodrigo Kumpera <kumpera at gmail.com>
>> > It depends on what patches. One I did merge had to be reverted due to
>> > causing deadlocks.
>> > On Tue, Nov 27, 2012 at 1:45 PM, Greg Young <gregoryyoung1 at gmail.com>
>> > wrote:
>> >> 3.0.1? We are seeing some of the same kinds of issues with TCP as
>> >> previously (eg call beginsend never get an endsend). There is
>> >> discussion in the history of the list. I can go figure out which
>> >> relevant patches might be missing but should we be expecting them to
>> >> have been brought forward?
>> Le doute n'est pas une condition agréable, mais la certitude est absurde.
Le doute n'est pas une condition agréable, mais la certitude est absurde.
More information about the Mono-devel-list