[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
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 at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- 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