Should this be the new default build for linux then? On Tue, Apr 23, 2013 at 4:23 AM, Rodrigo Kumpera <kump...@gmail.com> wrote: > The problem is specific to the epoll backed, if you disable it[1] your > problem is fixed. > I could repro it on linux-amd64 with epoll enabled but could not with it > disabled. > > The way to fix this is: > > -move locking to the epoll backend and make sure it works there; > -use a pipe like other backends to wake up the waiter and do all epoll ops > from a single thread > > > [1] Set the MONO_DISABLE_AIO env var > > We still have this patch that we use with mono. > > diff --git a/mono/metadata/threadpool.c b/mono/metadata/threadpool.c > index e8a2f1a..f83e473 100644 > --- a/mono/metadata/threadpool.c > +++ b/mono/metadata/threadpool.c > @@ -555,8 +555,8 @@ socket_io_add (MonoAsyncResult *ares, > MonoSocketAsyncResult *state) > > mono_g_hash_table_replace (data->sock_to_state, state->handle, list); > ievt = get_events_from_list (list); > - LeaveCriticalSection (&data->io_lock); > data->modify (data->event_data, fd, state->operation, ievt, is_new); > + LeaveCriticalSection (&data->io_lock); > } > > > We tried to submit this previously as it resolves our problems. It was > rejected that it introduces a deadlock. We have provided tests that > show without this change that TCP is basically unusable calls like > beginsend sometimes never call endsend. > > I would really prefer to not be distributing a "custom" version of > mono with this patch so how can we resolve this. > > Cheers, > > Greg > > -- > Le doute n'est pas une condition agréable, mais la certitude est absurde. > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list
-- Le doute n'est pas une condition agréable, mais la certitude est absurde. _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list