non se·qui·tur    [non sek-wi-ter, -toor; Lat. nohn se-kwi-toor] –noun 1. Logic. an inference or a conclusion that does not follow from the premises. 2. a statement containing an illogical conclusion.

Mechanical, I checked your profile. You've never authored an article, posted a snippet, entered a blog post, or otherwise shared any original thought, except to snipe at other people's comments on the message boards. In other words, you have yet to provide any empirical evidence for your worth to this site. No be a good boy and go away, please.

As someone who started out coding with 'vi' I find it amusing what people find annoying in modern IDEs. Sad that you wasted so much time, but if you think about everything the IDE was doing to help you ... not a lot to complain about there.

Do you normally have this kind of trouble with reading comprehension? I said I used up all the threads on purpose.

I know what you're saying, and I know what the article says, but I'm just not buying it. My experience tells me otherwise. I stress tested my service many times over what the hardware could handle, or what would be an expected load just to make sure it could handle it. I KNOW that I used up every thread in the thread pool because I did it on purpose. I had config options for the number of io threads and worker threads so I could set them explicitly. I set them with scaling values and pumped a massive amount of data through the system, on purpose, so I could find the sweet spot. I never saw a single dead lock. I say again, I think this is a lot of to do about nothing.

Okay, so now that I had some free time to go look into the article you linked in more detail, I don't think I agree with your assessment that this is dangerous. First of all, you will only deadlock if you starve off all of the threads in the thread pool and those tasks are all waiting on some task that is queued and can't run. Further reading confirmed my suspicions that this scenario is more likely to happen in an ASP.NET application. I wrote these for a windows service that has nothing to do with ASP.NET. On the one hand, I understand the danger posed, but I think you've greatly overstated the issue. I've used this pattern heavily and never seen a single dead lock, because the operations that I'm running are for the most part atomic. Parallel.ForEach, of course, was not available when I wrote this. So, there you are. Sadly, if you on .NET 3.5 you can no longer download the parallel extensions (there's a deprecated version under the NET2 namespace). Otherwise, you'll have to use .NET 4.0, and that's pretty green code right now.

FYI, I came up with these when I was writing a server that had to execute complex hierarchical queries of data from a distributed cache. Since each element each level in the object hierarchy was stored as an individual blob, simple iterative queries took forever. I parallelized the queries at each level for it's children this way. There was no danger of a deadlock, but I get your point. (giving someone enough rope to hang themselves... but in that case, they shouldn't be trusted with writing multi-threaded apps) BTW, this improved our performance by orders of magnitude, and saved us a lot of coding time, by just having an abstraction like this. So, if you still don't like it, don't use it. ;-)

Did I mention that this was an argument to string.Split() which is defined to take (params char[])? They could have simply typed: ';'

";".ToCharArray() 'nuf said.

Okay, I'll work on the article. Just don't tell my boss. ;)

I've created a whole bunch of parallel wrappers for the Func... and Action... helpers in .NET. It makes it much more convenient to execute stuff in parallel from the thread pool. There are multiple overloads for each overload of Func<> and Action<>, but here's one example:public static void Invoke<T1, T2>( Action<T1, T2> action, IEnumerable<object[]> args ) { List<IAsyncResult> results = new List<IAsyncResult>(); foreach( object[] argList in args ) results.Add( action.BeginInvoke( (T1)argList[ 0 ], (T2)argList[ 1 ], null, null ) ); foreach( IAsyncResult result in results ) { action.EndInvoke( result ); } }
And I can use it like this:class Program { static void Main( string[] args ) { ParallelAction.Invoke<string, int>( Foo, new[] { new object[] { "string1", 1 }, new object[] { "string2", 2 }, new object[] { "string3", 3 }, } ); Console.ReadLine(); } public static void Foo( string s, int i ) { Console.WriteLine( "Got: s={0}, i={1}", s, i ); } }
I have more complete versions that handle exceptions on threads, but those are too big to post here. Maybe I'll write an article later.

Here's my educated guess on what happened. It looks like this is a server-side exception in a WCF connection. I'll bet that the inner exception is something that you threw on the server side, but its not serializable, and so it comes through as null to the client. If you ever throw just "new Exception()" then it won't be serializable. Always use something that inherits from ApplicationException.

I got about halfway through the responses to this before I had to reach for my duct tape to prevent my head from exploding. No comments? Really? That's the stupidest thing I've ever heard. And I used to work for IBM. They collected statistics on klocs! So I've heard some pretty stupid things.

I got 51. But I type fast.

You can always use PowerShell extensions. It is very powerful, but not so intuitive.

You need to make sure you have compiled everything in DEBUG mode, and that you have access to the .pdb file generated by the compiler for the assembly you want to debug.

You don't mention what language you're developing in. If it is a .NET language, then .NET Remoting would be a perfectly acceptable tool.