[Mono-dev] TCP (threadpool.c)

Rodrigo Kumpera kumpera at gmail.com
Tue Apr 23 01:23:54 UTC 2013

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

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.



Le doute n'est pas une condition agréable, mais la certitude est absurde.
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130422/21e2a2f8/attachment.html>

More information about the Mono-devel-list mailing list