Forgive me for my sins

[AtW]

AtW: Visual Studio 2005 is a complete bitch when you're working with threadpools for a hefty distributed load testing tool. VS.Net just doesn't handle it well.

I use a lot of threads, plus threadpools indirectly (async HTTP and socket methods), all seems fine - much better than in VS 2003. Perhaps you have problem with default value of threads (25) in threadpool? Now that's fking annoying, but this is .NET framework's default, can be change programmatically.

[Paddy]

I remember installing 486 cards in Macs to allow dual boot. Personally I would rather use an Apple OS than Linux if I had to choose.

version 10 of the Mac OS is based on the Mach kernel and the BSD implementation of Unix which were incorporated into NEXTSTEP, the object-oriented operating system developed by Steve Jobs's NeXT company after he left Apple in 1985. It is near Linux than the older MAC versions.

[TheMonkey]

I use a lot of threads, plus threadpools indirectly (async HTTP and socket methods), all seems fine - much better than in VS 2003. Perhaps you have problem with default value of threads (25) in threadpool? Now that's fking annoying, but this is .NET framework's default, can be change programmatically.

Nah the threads all run time-critical FSMs (so there are up to 5000 FSMs running). Visual Studio doesn't like the fact it's shifting nearly 2Gb of FSM state data around the system so when something craps and you hit stop, Visual Studio goes WUMPH and dies

[AtW]

I hit one bug in .NET 1.1 where the damn thing enters kernel switching thing and this totally locks all networking everything, even though locally its possible to kill the app: I found that its a bug, but Microsoft does not offer anything better than hotfix that you cant be arsed to try to obtain, so I switched to .net 2.0 where it seems something similar happens when I try to bind to port under profiler, works fine otherwise though.

Anyway, if you use so many threads then maybe you should rethink your algorithms.

[TheMonkey]

I hit one bug in .NET 1.1 where the damn thing enters kernel switching thing and this totally locks all networking everything, even though locally its possible to kill the app: I found that its a bug, but Microsoft does not offer anything better than hotfix that you cant be arsed to try to obtain, so I switched to .net 2.0 where it seems something similar happens when I try to bind to port under profiler, works fine otherwise though.

Anyway, if you use so many threads then maybe you should rethink your algorithms.

I hit the same bugs I think.

The algorithm is fine. It's just doing one hell of a lot! Basically tasks are queued in order of when execution is due and 25 threads concurrently execute the states and call simple web services to perform actions. Depending on the state of the action another work unit is scheduled and added to the queue of work. The tasks can and will fail if they are executed late so some juggling is done if they are due to take longer than expected.

This beasty is about 60,000 (REAL ie no comments!!) lines of code so it's hard to debug due to the nature of the concurrency and complexity of the tasks

[AtW]

I think they have similar bug in .net 2.0 - in 1.1 when it was triggered it was the end of it, app dead but also kills networking, in .net 2.0 when I hit it under profiler (but nowhere else) it hogs CPU and seems to be doing kernel switching - you cant kill the app!, ffs, it should always be possible to kill application, but not in this case - this has got to be because this bug happens in some kernel bit so its not getting killed.

This bug that I hit seems to be linked very closely to TCP/IP stack - specifically in .net 1.1 it was happening in async socket callback, and in .net 2.0 in profiler it hangs when I try to bind socket to port.

[TheMonkey]

I've had that one!

[AtW]

Does it hang when trying to bind to socket, is it under VS 2005 or something else?

[TheMonkey]

Either then or when a thread is created.

It's definitely a race / deadlock under VS2005 as if you use the command line debugger it doesn't hang.

[AtW]

Does it happen when you run it standalone? The bug that I found was in framework itself, VS 2005 is a lot better IDE than VS 2003 that is slow in some debugging scenarios. The only thing that really pissed me off about both is that you can't debug C++ code with inlined assembly, even when stepping in Disassembly window!