Multi-Threading
Well, OK I’m over dramatizing it a tad :) As you may have noticed from my last post I’ve started working of some stuff which is outside my comfort zone. I recently joined a company called cozwecan,working for a chap named @RobertTheGrey, the first project we’re working on is a photo sales site…you know kind of like Getty Images / Smugmug / Flickr except for direct photographer-customer sales. As the only full-time developer (so far!) I’ve been tasked with building the vast majority of the applications (be they web, desktop, etc…) which we need for the business to work. ...
Should mention I suppose the I lied in yesterdays post on threading using .NET...mea cupla :-). In that post I mentioned using delegates for multi-threading and said that you always had to use EndInvoke to avoid a memory leak...well not quite, what i actually do is use the excellent AsyncHelper class by Mike Woodring, this supports this syntax: CalcAndDisplaySumDelegate d = new CalcAndDisplaySumDelegate(someCalc.Add); AsyncHelper.FireAndForget(d, 2, 3);No EndInvoke required as it takes care of this using a DynamicInvoke internally. Well, saves a few lines of code!
I'm getting increasingly involved in the world of Asynchrony and have been doing a bit of digging about into some of the pitfalls of multi-threading. I came across an interesting one today involving the use of BeginInvoke without a corresponding EndInvoke when using delegates...many books (including the one I'm using most right now, the excellent Programming .NET Components by Juval Lowy) mention that a good way to fire events asynchronously (i.e., not blocking) is to simple call BeginInvoke on the delegate - cool seems easy enough! Well, reading around a bit, I discovered this by Mike Woodring which contains this statement:...
I posted a little while ago about an odd 'Memory Leak' I was having...well, after several days of trawling (and annoying Data Wanta who's excellent email component I was mistakenly blaming - sorry!), I finally found the answer! Turns out that the little [STAThread] attribute above the main class of the Comand Line app isn't so inoccuous after all - Dave pointed out this thread - apparently there's some sort of bug in .NET which can lead to what is effectively a leak when using multi-threading in a STAThreaded application!