On 2 Feb 2007 07:32:14 -0800, billie <[EMAIL PROTECTED]> wrote: > > This is not a CRASH, It looks an exception with a "Traceback", this is > > the normal way python report problems, nothing wrong with that. > > You can handle it with a try: except: > > I think that such a thing should be handled by asyncore itself. >
Handled by doing what, exactly? > > 512 is probably a fixed limit into XP, win2k3 or win2k server will > > accept more. > > Maybe It's possible to increase this value somewhere in the registry. > > If not this is how microsoft justify the difference between server and > > workstation products :-) > > Yeah, maybe... > > >> Why does this exception isn't handled inside asyncore.py? > > To do what ? To raise a custom asyncore error ? > > asyncore aims to be a framework, right? > I think that when select() limit is reached asyncore should just drop > other connections. That's all. Silently rejecting connections in a way that is invisible to the application is clearly the wrong thing to do. > > > You can can probably run over this limit by starting multiple of your > > server process (not thread, process). > > Hope you're joking... > Why should I have to run multiple processes / threads to avoid such a > problem? Thats like asking why you should have to move your fingers to type or why you should have to eat food in order to not starve. Windows is placing a limit of 512 descriptors per process. Call Microsoft if you want to go over that. Or, you can volunteer to write a win32 port of asyncore that uses native winsock functions instead of the BSD compatibility functions. > And what if my system / inteprepter does not support multiple > processes / threads? > What if it doesn't support sockets? This is a platform limitation, not an arbitrary Python one. Nothing Python is going to do is going to convince Windows to select() on more than 512 file descriptors per process. -- http://mail.python.org/mailman/listinfo/python-list
