Raymond Chen has just blogged about “The importance of the FORMAT_MESSAGE_IGNORE_INSERTS flag” over on The Old New Thing. That’s another annoying bug fixed ;). I’ve occasionally wondered why I get some less than informative error messages sometimes, I wasn’t passing the flag in my GetLastErrorMessage() function and it calls itself if FormatMessage() fails and so sometimes I get an “invalid parameter” error messages when what I could get might actually be more useful to me.
I’m currently rebuilding my world with Visual Studio 2008. So far things are going ok, but as I mentioned back when I was playing with Beta 2, the new C4627 warning about header files being skipped when processing precompiled headers is a bit broken…
It seems that the code that works out if a header file is skipped (ie not included in the precompiled header but above the #pragma hdrstop line works on exact path matches rather than a file include graph.
After completing some work for client with the custom CLR hosting server I’ve started looking into a problem for another client, it’s a bit of a transition as the problem that he’s having is with a DDE connection from his server to a SCADA system that monitors the industrial plant where the server is based.
DDE was the original way that Windows programs shared data between them. It’s been around since 1987 and, well, that shows.
I’m looking into adding CLR deadlock detection into the CLR hosting code that’s used inside The Server Framework and, once again, the fact that you can’t cleanly shutdown the CLR host is causing me problems…
Since the CLR can’t be stopped by a host without terminating the host process (and that’s by design…) you need to be aware that any of the code that you have plugged into the CLR by way of the hosting interfaces can be called into during process shutdown.
Once again Rands hits the nail on the head with The Nerd Handbook…
My current server development for a client has been going well but this week I finally got to the point where I wanted to look at the peformance counters it was presenting and they weren’t showing up in perfmon. My daily development for most projects is on my x64 box and I was building the server in x86 mode and although it was registering its counter DLL correctly it was an x86 DLL and the x64 perfmon can’t load x86 counter dlls.
I ran into an unexpected issue with OnSocketReleased()yesterday whilst writing a connection filter for a client. OnSocketReleased() is a callback method in The Server Framework that allows you to ‘do stuff’ at the last possible moment of a connection’s lifetime. It’s guaranteed to be the last callback ever called for a connection and it’s guaranteed not to be called until all references to a connection have been released; so you can’t get caught out by other threads still processing other last minute connection shutdown events.
Continuing last week’s theme of being wrong, ‘M’ pointed out to me in a comment on my posting about changing the memory allocation strategy for the IO buffer allocator that I actually have a bit more work to do… I’d forgotten that VirtualAlloc() allocates in terms of the memory allocation granularity of the operating system…. So, at present, the quick and dirty fix that I posted is allocating buffers in blocks of at least 64k of memory… They are, at least, page aligned ;) Thanks for pointing out the error of my ways, comments like this are one of the main reasons that I blog.
Whilst being wrong this week I reviewed some of the other socket server entries on this site and was reminded of an item that’s on a todo list somewhere by a comment on this posting from Matt: “What do you think about using VirtualAlloc to allocate page-aligned memory for the receive buffers? Would it reduce the number of locked pages? I mean if you allocate a buffer of ‘page size’ using ’new[]’ it is very likely that the buffer uses 2 pages instead of 1.
This week I’ve spent some of the time being wrong, which has proven useful as I’ve learned quite a lot and clarified my understanding of a situation. It all began when I had a bug report from a client who claimed that an obscure internal part of The Server Framework wasn’t working as he expected it to…
The report said that the m_outstandingWrites variable of the TAsyncSocket sometimes ‘stays above 2’.
