The latest release of the licensed version of the socket server framework is now available. This release includes the following changes.
The following changes were made to the libraries.
_WIN32_WINNT >= 0x0600 and JETBYTE_PLATFORM_SDK_VERSION < 0x060A as targetting Vista or later means we enable stuff that's only available in the v6.0a Platform SDK.JETBYTE_PLATFORM_SDK_VERSION == 0x0610 and we're building with anything earlier than VS2005 as version 6.1 of the Platform SDK defines a 'clever' template version of _WSPIAPI_COUNTOF from WSPIAPI.H and the earlier compilers can't deal with...JetByteTools::Win32::ICollectableThreadPool and JetByteTools::Win32::CThreadPoolCollection which allow you to dispatch items to a named thread pool to facilitate multiple thread pools for different types of work item.JetByteTools::Win32::CThreadPool::WaitForShutdownToComplete() now returns a bool which is true if threads were terminated forcibly rather than being allowed to shutdown cleanly.JetByteTools::Win32::CThreadPool::DisposeOfQueuedItems and JetByteTools::Win32::IThreadPoolWorkerThreadFactory::DisposeOfQueuedItemsAfterShutdown() which work together to allow you to process all work items that were held in a thread pool's queue after the pool has been shutdown. This should be used to release resources used by items that were placed into the queue but that will now never be processed.JetByteTools::Win32::CIOCompletionPort timeouts.JetByteTools::Win32::CThread::StartWithPriority(), JetByteTools::Win32::CThread::EnableThreadPriorityBoost(), JetByteTools::Win32::CThread::DisableThreadPriorityBoost(), JetByteTools::Win32::CThread::ThreadPriorityBoostEnabled(), JetByteTools::Win32::CThread::SetThreadPriority() and JetByteTools::Win32::CThread::GetThreadPriority().JetByteTools::Win32::CSmartStatupInfo which takes ownership of any input or output handles supplied to it or creates the files and takes ownership of the handles if given file names.JetByteTools::Win32::CMultipleFileDeleter which is a bit like JetByteTools::Win32::CFileDeleter but for multiple files...JetByteTools::Win32::CJob, JetByteTools::Win32::CJobEventManager, JetByteTools::Win32::IMonitorJobs, JetByteTools::Win32::IManageJobEvents, JetByteTools::Win32::IHandleJobEvents, JetByteTools::Win32::IAssignProcessesToJobs and JetByteTools::Win32::CNullJobMonitor which, together, allow you to manipulate Windows Job Objects.JetByteTools::Win32::CCallbackTimerQueueEx which uses JetByteTools::Win32::IProvideTickCount64 as its time source. See here: http://www.lenholgate.com/archives/000773.html for more details.JetByteTools::Win32::CCallbackTimerQueue to the one that is detailed here: http://www.lenholgate.com/archives/000773.html.JetByteTools::Win32::CThreadedCallbackTimerQueue so that you can select which underlying timer queue implementation it uses, or provide a custom one of your own, and so that you can request that it dispatches timers without holding any internal locks. Note that the default behaviour is to hold the internal lock and this behaviour is backwards compatible with the previous releases. However, in certain designs, this makes it easy for you to deadlock. If you have a lock and you hold it whilst calling into any of the timer queue functions, and you try to acquire your lock when the timer queue calls into you then you will deadlock. Not holding the internal lock during timer dispatch means that you can't deadlock when using the timer queue but the dispatch code is possibly slightly slower. This may be important to you in certain situations so we currently provide the choice. The changes are detailed here: http://www.lenholgate.com/archives/000795.htmlJetByteTools::Win32::CThreadedCallbackTimerQueue::SetThreadName() which allows you to change the name of the timer queue thread. This name is displayed in the Visual Studio Debugger's thread window. The constructor now sets the name of this thread to "TimerQueue" by default.JetByteTools::Win32::CThreadPool::SetThreadName() which allows you to change the name of the worker threads that are managed by the pool. The constructor now sets the name of these threads to "ThreadPool" by default.JetByteTools::Win32::CThreadPool::SetDispatchThreadName() which allows you to change the name of the dispatch thread that is used by the pool. The constructor now sets the name of this thread to "ThreadPoolDispatch" by default. Note that this must be called before calling JetByteTools::Win32::CThreadPool::Start() for it to have an effect.JetByteTools::Win32::CThreadPool::SetThreadName() which allows you to change the name of the worker threads that are managed by the pool. The constructor now sets the name of these threads to "ThreadPool" by default. Note that this must be called before calling JetByteTools::Win32::CThreadPool::Start() for it to have an effect.JetByteTools::Win32::CThreadPool::WorkerThread::Run() now catches exceptions of type JetByteTools::Win32::CSEHException that leak from JetByteTools::Win32::IIOCPWorkerThreadCallback::Process() and tries to shut the worker thread down cleanly; it might work in some cases.JetByteTools::IO::CBufferHandleAllocator. This provides a pooling allocator for JetByteTools::IO::CBufferHandle objects. Buffer handles are used to broadcast data to multiple clients without needing to copy the data into separate buffers.JetByteTools::IO::CJobEventManager. This works with the job object support in the Win32 Tools Library to provide an event manager which can work with a JetByteTools::IO::IIOPool.JetByteTools::IO::CMemoryInputOutputStream where we were using delete rather than delete [].JetByteTools::IO::CInOrderBufferList::Size() which returns the number of buffers in the list.JetByteTools::IO::IBuffer::GetWSABUFCount(). This returns the number of WSABUFs in the array returned by JetByteTools::IO::IBuffer::GetWSABUF(). At present all buffer implementations return 1 for this, but this will allow for buffers which support 'scatter/gather' style multiple buffer writes.JetByteTools::IO::IAllocatableBuffer which goes some way to being able to share the pooling aspects of the various buffer allocators.JetByteTools::IO::CIOPool::SetThreadName() which allows you to change the name of the worker threads that are managed by the pool. The constructor now sets the name of these threads to "IOPool" by default. Note that this must be called before calling JetByteTools::Win32::CIOPool::Start() for it to have an effect.ConnectionErrorSource.h header file and the whole concept that the enum represented. This has also led to the removal of the various OnConnectionError() callbacks as these errors are now handled by more appropriate callbacks.JetByteTools::IO::IBuffer::GetWSABUFCount() so that we can work with buffers that provide multiple WSABUF structures. Note that there aren't actually any buffers in the library that do this yet.JetByteTools::Socket::CReadSequencingStreamSocketConnectionFilter now takes an instance of JetByteTools::Socket::IAllocateSequencedStreamSockets rather than JetByteTools::Socket::IAllocateStreamSockets. It actually only requires the opaque user data part of the interface but this change makes it clearer that the filter only works with sequenced sockets...JETBYTE_PLATFORM_SDK_VERSION == 0x0610 and we're building with anything earlier than VS2005 as version 6.1 of the Platform SDK defines a 'clever' template version of _WSPIAPI_COUNTOF from WSPIAPI.H and the earlier compilers can't deal with...JetByteTools::Socket::CAddressRenderer so that it always passes NI_NUMERICSERV to JetByteTools::Socket::CNameInfo as otherwise you get a WSANO_DATA error on some Windows platforms if the port isn't a "well known" port.Full details of the free version of the code are available here.
Doxygen documentation for the 5.2 release is available here.
If you're an existing client and you'd like these changes let me know.