I’m playing around with hosting the CLR in C++ at present and have come across a bit of crapness in the mscoree.h file…
#if (_MSC_VER < 1300 || _WIN32_WINNT < 0x0500) typedef VOID ( __stdcall *WAITORTIMERCALLBACK )( PVOID __MIDL_0011, BOOL __MIDL_0012); #endif // (_MSC_VER < 1300 || _WIN32_WINNT < 0x0500) This effectively says, if you’re using VC6 or you’re compiling for less than v5 of Windows NT then you don’t have this typedef so here it is… Unfortunately, if you’re compiling with VC6 but you’re using the platform SDK then you already have that typedef in winbase.
Here are a few interesting views on software development from Katie Lucas. Via Joel on Software. I especially enjoyed the design methodologies, becoming a manager and “remove developers net access” pieces.
The latest version of The Server Framework contains a memory leak in the CSocketServerEx class. It’s quite a good leak, it leaks an IO buffer on every connection attempt. The fix is as follows:
Change this code:
void CStreamSocketServerEx::PostAcceptRequest() { if (m_listeningSocket != INVALID_SOCKET) { if (m_connectionLimiter.CanCreateConnection()) { IncrementPendingReceives(); const IFullAddress &address = GetAddress(); IStreamSocketEx *pSocket = AllocateSocket(CreateSocket(address.Type())).Detach(); IBuffer *pBuffer = AllocateBuffer(); pBuffer->SetUserPtr(m_socketIndex, pSocket); PostIoOperation(pBuffer, IO_Accept_Request); } else to this:
I’ve just fixed a problem in The Server Framework that was reported to me by one of my clients. There’s a race condition during connection establishment which can be demonstrated by a client that connects and then terminates the connection very quickly. The bug could be said to be in the example servers rather than the framework itself but it can be fixed by a change to the framework…
In the non AcceptEx() version of the TCP server code, during connection establishment OnConnectionEstablished() is called from the code that processes a successful Accept().
Normal service is about to resume… I arrived back in the UK yesterday evening after lots of good skiing in France and Switzerland. Conditions in France could have been better (it’s still best to hire skis or use your rock skis - in Avoriaz at least!) but that only served to make us realise how good the conditions had been in Switzerland. I now have a couple of weeks to get some work done and let my legs rest before 3 weeks in Jackson Hole…
I’ve adjusted how I deal with comment spam and the comment system should now be active again…
I’m back in the UK briefly on 28th and 29th December and then I’m off to Davos for new year… I’m back in the UK in early Feb and then ski guiding for the Ski Club of Great Britain in Jackson Hole for 3 weeks from 17th Feb…
Meanwhile, I’ll continue doing slalom training in Tignes in the French alps…
Beware, those poles are addictive!
I’ve just had an question from a reader via email:
“I’m developing my huge server (I dont have much experience with programming servers) and as far as I know your source is the best available out there.. I would like fit it to my needs and use more c++ standard template libary instead of those buffer/linked list classes you made by yourself, but I’m afraid it would end in loss of preformance speed.
I’ve just made a small change to The Server Framework. The change is in how the AsyncConnect() function reports connection errors and the potential problem can occur if there’s a race condition between a call to Close() on a socket that has not yet successfully connected. If the call to Close() completes before connection is attempted by the IO thread pool (possible but usually unlikely in normal operation) then the connection failure doesn’t currently make its way back to OnOutgoingConnectionFailed() which means that any code you might have in there for dealing with connection failures wont get called…
