- Bug fix to
JetByteTools::Socket::CStreamSocketConnectionManagerfor writes that involve buffer chains. as with the bug in
JetByteTools::Socket::CFilterDataBase::OnWrite(), we were relying on the Windows XP write sequencing code to ensure that multiple buffer writes were written sequentially without any other writes occurring in between the write of each buffer from the chain. Without the write sequence number it was possible that the buffers would be intermingled with those from another write on another thread and this the correctness of the stream would be destroyed. We now handle chains with more than one buffer as an atomic unit and pass the chain itself into the write using an array of
WSABUF's and deal with splitting the chain during completion handling. This bug was introduced in 6.7.
- Bug fix to
JetByteTools::Socket::CFilterDataBase::OnWrite()where a buffer chain is passed. We were previously dispatching the buffers separately by iterating the chain and pushing each buffer into the filter. This worked fine until we removed write sequencing in 6.7 as this was only required for Windows XP. The write sequencing was ensuring that our splitting the buffer chain as it entered the filter worked correctly as the filter then resequenced the buffers using the write sequence number. Without a write sequence number it is possible that the buffers would be intermingled with those from another write on another thread. We now handle chains with more than one buffer as an atomic unit and pass the chain itself into the filter and split it inside where we are guaranteed not to be preempted by another thread.
- Bug fix to
JetByteTools::Socket::CFilterDataBasewhere we were being too aggressive in recognising the read side of the connection being closed and restricting further application level reads. This resulted in a race condition during receipt of a client close whereby a filter could end up with data available to read inside it but no further application level reads would be processed. This would result in the final data on a cleanly closed connection being appearing to have been lost even though it had arrived successfully.
- Bug fix to
JetByteTools::Win32::CJob::QueryInformation()which limited the information returned to the first 10 processes.
- Bug fix to
JetByteTools::Win32::CThreadPoolExso that it deals better with fixed sized thread pools.
- Bug fix to
JetByteTools::Win32::CUTF8StreamConverter::AtoUTF8()to remove a locale leak.
- Bug fix to
JetByteTools::IO::CAsyncFileWriterto do with how and when it notifies on the last write completion. This allows for setting the flag to notify multiple times through the lifetime of the object and makes the definition of 'last' a little clearer in these circumstances.
- Dropped support for Visual Studio 2010.
- Removed support for Visual Studio 2013 Preview and code reliant on
- Removed support for STLPort. This is no longer required as the quality of the STL implementation supplied with Visual Studio has improved immeasurably.
JetByteTools::Win32::CThreadPoolCollectionhas been deprecated and is no longer available unless you define
JETBYTE_DEPRECATE_THREAD_POOL_COLLECTIONto 0 in Config.h. This code was only ever used for one client and should have been client specific.
JetByteTools::Win32::TSingletonhas been deprecated and is no longer available unless you define
JETBYTE_DEPRECATE_SINGLETONto 0 in Config.h. As the comments with the class say, "Remember, Singletons are EVIL! and what's more they're generally unnecessary".
JetByteTools::Win32::TLinkedClasshas been deprecated and is no longer available unless you define
JETBYTE_DEPRECATE_LINKED_CLASSto 0 in Config.h.
JetByteTools::Win32::CActivatableObject::Callback::OnActivatableObjectProcessCommand()to both return
boolif you return
falsethen you will not be called again if more commands are currently queued until another new command is queued or until
JetByteTools::Win32::CActivatableObject::ProcessQueuedCommands()is called. This allows an activatable object to prevent itself from hogging a thread by only allowing a set number of commands to be processed before it forces the caller to 'take a break'. If more commands would have been processed at this time but cannot due to the callback returning
JetByteTools::Win32::CActivatableObject::Callback::OnActivatableObjectMoreCommandsToProcess()is called to notify the object of the situation. The idea is that the object can then do something to schedule future processing of these unprocessed commands. The first time commands are processed a call to
JetByteTools::Win32::CActivatableObject::Callback::OnActivatableObjectAboutToProcessCommands()is called so that the object can reset its 'number of commands processed this time around' counter...
JetByteTools::Win32::CActivatableObject::QueueCommandForProcessing()to take an enum for
ProcessingFlagsrather than just a
booleanflag. This allows you to pass the following mutually exclusive flags;
JetByteTools::Win32::IManageTimerQueue, see here for details.
- Renamed the static
JetByteTools::Win32::IWaitable::WaitForHandle()so that classes that implement the interface don't hide the static functions by implementing the non-static wait function.
- Renamed the
#definethat is used to cause a
JetByteTools::Win32::CLockableObjectto fall back on a reentrant implementation based on
JetByteTools::Win32::CCriticalSection. This was called
JETBYTE_HAS_SRW_LOCK_TRY_ENTERand it's now called
JETBYTE_LOCKABLE_OBJECT_USE_CRITICAL_SECTIONS. The reason for this is that now all supported platforms have
1but there are still some good reasons for running with the critical section implementation in some situations. The renaming makes the choice more obvious.
- Removed the entire
JetByteTools::Win32::CThreadedCallbackTimerQueue. Since 6.7 we have been ignoring everything except the locking flags and now that they have been removed there is no need for the enum at all. This is a breaking change. Where the enum was previously used you must delete it.
- Changed function signature for
JetByteTools::Win32::IRunnable::Run()so that it returns an
unsigned inrather than a
JetByteTools::IO::CLockFreeBufferAllocatorhave been deprecated and are no longer available unless you define
JETBYTE_DEPRECATE_LOCK_FREE_BUFFERSto 0 in Config.h. If it's found that there is widespread use of these buffers then we will refactor them so that there is less duplicate code between them and the non-lock free version.
- Changed how
JetByteTools::IO::CIOPoolbase calculates the number of threads required if
0is passed in. Previously it was
2 * number of processorswhich worked fine back in the day but now it tends to create pools with too many threads. Now it caps this calculation at
4. If you're relying on passing <0> to get a large number of threads then you should specify the required amount explicitly.
JetByteTools::Socket::CCompressingStreamSocketConnectionFilterand associated code.
JetByteTools::Socket::CFullAddress::GetWritableAddressRef()as it doesn't inherit from
JetByteTools::Socket::IWritableAddress. If this breaks any code then I'll put it back and ensure that it also inherits correctly.
- Removed support for versions of OpenSSL prior to 1.1.0c
JetByteTools::OpenSSL::CUsingOpenSSLas it is no longer required.