* use override
* use make_shared
* use emplace
* use range for
* fix error on MSVC
* replace boost functions with std functions
* fix static analyzer warnings
* check api return value
* initialize member
* check the return value of SSL_peek > 0
* add override
* make use of C++11 override keyword
* added const specifier to TTransport::getOrigin()
* added more const correctness to the compiler
* make use of auto keyword
* replaced usage of NULL with nullptr
* make use of explicitly-defaulted function definition
* extended changelog
To ensure there are no include path collisions the C and C++ header
include paths should include 'thrift' as the root leaf. This will
prevent having to place /usr/include/thrift into the compilers include
header search path, which might otherwise result in the compiler
accidentally picking up headers that it shouldn't.
e.g. #include <foo/bar.h> should be #include <thrift/foo/bar.h>
Change-Id: I48f2b0f549bda0fc81e85506ac857adc800b98a1
git-svn-id: https://svn.apache.org/repos/asf/thrift/trunk@1325674 13f79535-47bb-0310-9956-ffa450edef68
The boost test framework has changed significantly from boost 1.34 to
1.37. Quite a few new features have been added, and some annoying bugs
have been fixed.
This change now builds the thrift tests against boost 1.37, and updates
them to use some of the newer features.
git-svn-id: https://svn.apache.org/repos/asf/incubator/thrift/trunk@1005162 13f79535-47bb-0310-9956-ffa450edef68
Previously flush() had race conditions that could cause it to return
before all data had actually been flushed to disk. Now the writer
makes sure both buffer queues have been flushed when forceFlush_ is set.
Also, flush() did not wake up the writer thread, so it normally had to
wait for the writer thread to wake up on its own time. (By default,
this could take up to 3 seconds.)
git-svn-id: https://svn.apache.org/repos/asf/incubator/thrift/trunk@1005156 13f79535-47bb-0310-9956-ffa450edef68
Several of the TFileTransportTest tests check wall clock time to make
sure the writer thread processes operations quickly enough, and isn't
hanging. However, this can easily result in false failures if we don't
get enough processor time. This commit makes a few changes to reduce
the number of these failures.
- No longer fail if a single destructor call takes more than 500us.
We only require 90% of the calls to complete in 500us. No call may
take more than 100ms, though. With this change, the test passes most
of the time now, even while an "fbmake opt" task is running in
parallel.
- In the flush_max_us tests, make sure the writer thread is started
before we start recording timing. Otherwise, creating the thread
could take long enough to throw off the numbers for the first fsync()
call.
Also tested with the pthread_cond_signal() in the TFileTransport
destructor commented out, to make sure the test still fails properly
when the destructor takes too long.
git-svn-id: https://svn.apache.org/repos/asf/incubator/thrift/trunk@1005155 13f79535-47bb-0310-9956-ffa450edef68
Set closing_ to true before we wake up the writer thread in the
destructor. This way the writer thread flushes the data and exits when
it is woken up.
Previously the writer thread could end up going through 2 full timeout
cycles before exiting. The writer thread could wake up, notice it has
nothing to do since closing_ is not set, and immediately go back to
sleep. The destructor would then proceed to call flush(), which would
wait for the writer thread to wake up (1 full time out) and clear the
forceFlush_ flag. After flush returns, the destructor would set
closing_. It could take the writer thread another full timeout to wake
up again and process this flag.
There were also some points where the worker threads would detect the
closing_ state in their loops and automatically close the file, but did
not zero out the file descriptor, then the destructer attempted to close
the same file. Fix by simply zeroing out the fd_ at these points.
git-svn-id: https://svn.apache.org/repos/asf/incubator/thrift/trunk@1005154 13f79535-47bb-0310-9956-ffa450edef68