[Python.NET] Python.Net affected by currently somewhat broken .Net Multithreading?

[Martin Kretschmar]

Hello,

the well respected german computer magazine c't reports in an article
of its release 26/03 on page 214, that the .Net multithreading support
currently suffers from several strangeness factors.

The class ThreadPool suffers from several anomalies:

The thread pool of a process is limited by 25 threads per processor.
GetMaxThreads() and GetAvailableThreads() deliver the values 25/25
with .Net 1.0 and 25/1000 with .Net 1.1.

The new threads obey to a pretty ackward activation pattern, new
threads are started with individual offsets of 500ms to each other!

The garbage collector starts after one minute after the demise of a
thread. If new threads are requested in between, one again suffers
the 500ms penalties from above.

Further experiments trying to start all required threads in advance
suffered from being queued automatically from thread 25 on, so
this didn't help so much either.

Running one thread under full load, makes the system take up to
5 seconds to start another thread.

Attempts to work without ThreadPool suffered also from several
anomalies and could even crash the .Net executive:

The executive is quiet sensitive when one tries to Resume() an
already running process etc, which might mean some extra
private bookkeeping.

Attempts with subclassing BaseThread worked but occasionally
resulted in a termination with return code 0 with .Net 1.0 and a
reported stack overflow with .Net 1.1.

Closing a window while one owns homemade background thread
is running creates a zombie thread.

Altogether the authors hope, that further releases of .Net like
.Net 2.0 will help to improve the situation.

Regards,
               Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20040110/8a5bf62c/attachment.html