It works fine on .Net of course, 200+ connections and no blocking, but on mono we're outta luck.
I'll probably just write an alternative code path for mono - at least for the moment.
Scott Manley
El vie, 07-05-2004 a las 20:59, P Oscar Boykin escribi�:/ Thanks for pointing out this article./>/ />/ This appears to be my problem:
/>/ />/ When I have enough sockets waiting on a BeginReceive, I cannot do
/>/ any other Async method. I guess the worker queue gets filled with the
/>/ BeginReceive calls, and then BeginSend calls cannot get through.
/>/ />/ For our work, the limit of 25 ThreadPool threads waiting on tcp sockets
/>/ is just not going to work.
/>/ />/ It seems like there are two options here:
/>/ />/ 1) Avoid Async socket operations for systems that need to scale to large
/>/ numbers. Prefer Select I guess.
/>/ />/ 2) Reimplement the Async sockets to make sure they always use native
/>/ operating system asynchronous facilities.
/>/ />/ I think you already said that in the 2.6 kernel, the Async Sockets use
/>/ the posix aio interface.
/>/ />/ It seems like in linux 2.4 there is a means to get the kernel to send
/>/ signals a socket is ready for IO:
/>/ />/ http://www.kegel.com/c10k.html#nb.sigio
/>/ />/ What would be the issues with doing a 2.4 implementation using the
/>/ signals mechanism?
/
The native AIO interface support, apart from having some weird bugs and
being disabled now, cannot be used always. Why? aio_read/write do not
support passing extra sockets options.
I tested it under 2.4 and 2.6 kernel and it works (apart from the weird bugs) fine.
I will reenable it once the bug is fixed.
Anyway, I suggest to use Select when you have such a big number of sockets doing asynchronous operations.
-Gonzalo
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
