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’.

I’ve finished porting my debugging tools support libraries to x64 now and thought it was worth putting up a summary of the issues that I’ve noticed: A 32bit exe can’t start a 64bit exe for debugging - pretty obvious really. When a 64bit debugger is running a 32bit debugee the debugger seems to get TWO “loader breakpoints” one when the 64bit dlls are loaded and a second when the 32bit dlls have been loaded.

The x64 version of our I/O completion port based, networking client and server framework, The Server Framework, is now shipping. This is the licensed version of the free server framework that’s available here. An overview of the licensed version can be found here. The changes from that version to the latest version can be found here. The documentation for this version is available online, here. Please be patient, the docs are a work in progress and I know they could be better.

It seems that I’ve located the “issues” in my Debug Tools library. This library is used in my TickShifter (time control) tool and my native Win32 Deadlock Detection tool. Due to how I wanted to control the debugged processes start up and how I needed to halt the debugged process at a particular time there were some hoops that I found I had to jump through. Those hoops have changed shape; either because of differences between Vista and XP or due to x64 and the WOW64 layer, I’m not sure which yet.

I should be finishing some docs for the x64 release of The Server Framework… But this is more interesting… When running my Win32 debugging code on x64, this time when compiled natively as x64 code and when debugging an x64 CLR process, I’ve been getting an ‘unexpected’ ExceptionCode in an EXCEPTION_DEBUG_EVENT. The code is 0x4000001f and, after some searching around, it seems that it’s a STATUS_WX86_BREAKPOINT event and I sometimes get these instead of EXCEPTION_BREAKPOINT events…

I spent a little time looking at an x64 port of my debugging tools library at the weekend. Since this requires me to set breakpoints and manipulate process memory and image files and all sorts I expected it to be a little more complex to port than the higher level sockets code and the bulk of my Win32 code. So far things are going reasonably well, but I’ve just come across a strangeness with DebugSetProcessKillOnExit(TRUE) in an x86 debugger that’s running an x86 process on an x64 machine.

Sad but true… The “Typical Programmer” has a piece on Thirteen Patterns of Programmer Inverviews. I think I’ve probably been interviewed in all of these styles over the years and taken part in several of them from the interviewing side of things…