Sunny wrote:
How would this help when I need to use async sockets? I can't say that async callbacks stay blocked for a long time (CPU usage is very low and they don't do anything heavy), but this limit certainly causes fatal problems in .NET. Mono seems to be okay without programmatical change, but I wonder if it still has that limit and just queues things, which could result in timeouts if number of async sockets is much higher than internal limit on number of threads.On Thursday 21 April 2005 09:53, Alex Chudnovsky wrote:
Yes, this does not help you when dealing with blocking sockets. So maybe it is better to implement your own dynamic size pool to handle this. Or, if these threads stay in blocked state very long, maybe you will find that just
I understand desire to have maximum compatibility with actual .NET, but surely having higher limits on number of threads is not something that would be bad? From what I understand Windows Socket IO uses Completion Ports (whatever it is) that are supposedly more efficient, if thats indeed the case, then I suppose Mono will need more threads available to make up for having less efficient socket IO?
regards,
Alex _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
