[
https://issues.apache.org/jira/browse/THRIFT-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rush Manbert updated THRIFT-311:
--------------------------------
Attachment: ThriftMsvcPatchForSvnRev808166.txt.zip
ThriftMsvcPatchForSvnRev803313_Rev1.txt.zip
Updated patches for Thrift MSVC Port
27 August 2009
There's nothing like taking your code out into the real world to find out
what you screwed up.
These patches (for 2 different SVN revisions) do the following:
* Fixes a bug in all flavors of TAsioServerSocket that made the interrupt()
method do nothing. The result was that calling stop() on a TServer whose
underlying socket used the TAsio* implementation did nothing and the server
thread would not be stopped. On Windows, the named pipe connect call was made
to be interruptible.
* In order to test that you really can stop the servers, I changed stress-test
so that it stops the server it has running when the test has completed
successfully, and waits for the thread to join. This means that we know
the server object's address and remember it, and that we specifically
make the server thread joinable when it is created.
* On Windows, added the capability to select static runtime linking for the
libraries and executables. To use this configuration option, your Boost
and Zlib libraries must be linked the same way. The default linkage is still
to the DLL runtime libraries. Run "cscript configure.js --help" for
usage information. If you select this option, the default Boost library name
paths are adjusted automatically. Since the zlib project does not support
this type of linkage out of the box, the same default patterns will be used
for either type of runtime linking. See the next item if you need to handle
modified file names for zlib libraries.
* On Windows, changed the configure script so that it accepts configuration-
specific library name search patterns for both Boost and Zlib. This lets you
specify things like:
--with-zlib-lib-name-pattern[win32][static][debug]=zlib-Win32-sd\.lib
and that pattern will only be used to search for the zlib library for
the configuration tuple (win32, static, debug). Of course, if you are
doing something nonstandard (as we are where I work), then you probably
need to specify the pattern for every tuple of interest. But at least
you can.
* On Windows, I put dummy versions of the property sheet files the configure
script generates into the configGenerated directory. This lets you open the
Visual Studio projects even if you haven't run the configure script. The
main reason is that you might need to upgrade all of the VS projects to
be compatible with a newer version of Visual Studio, and it's easier if
you can just open them without needing to configure first.
If anyone is playing with the patch, I apologize for the server bug. I had
halfway implemented it, but then never tested it. And if anyone wanted to
play on Windows but was thwarted by static runtime linking or nonstandard
library names, I apologize for the delay in supporting them.
I have a sneaking suspicion that there might be a need for some way
to customize the VS project settings via user-defined property sheets. (Well,
there might be this requirement if anyone but me ever uses this stuff.)
I didn't need them, so didn't put in the work required to add the capability.
It would require a configure command line parameter something like
--prop-sheet=myPropSheet.vsprops
and the configure script would write a property sheet that inherits from
that one, and all of the Visual Studio projects would inherit the property
sheet that we write. If there are no --prop-sheet arguments, then we would
write a property sheet file that doesn't do anything. Not particularly hard,
just tedious and time consuming to test.
There are 2 patch files:
* The first is a new patch that is to be applied to Subversion rev 803313.
It is called:
ThriftMsvcPatchForSvnRev803313_Rev1.txt.zip
(yes, I remembered to compress it this time) and it supersedes the previous
patch file called:
ThriftMsvcPatchForSvnRev803313.txt
(i.e. just apply this patch directly to a checkout of 803313, NOT to
a checkout that you already patched.)
* The second is made against a newer HEAD rev of the repository. It is
made to be applied to a checkout of Subversion rev 808166, and is called:
ThriftMsvcPatchForSvnRev808166.txt.zip
Apply the patches with -p8, as before.
> ASIO client & server
> --------------------
>
> Key: THRIFT-311
> URL: https://issues.apache.org/jira/browse/THRIFT-311
> Project: Thrift
> Issue Type: Sub-task
> Components: Library (C++)
> Reporter: Esteve Fernandez
> Attachments: MsvcPatchSupportScripts.zip, thrift_connection.cpp,
> thrift_connection.hpp, thrift_connection_v2.cpp, thrift_handler.cpp,
> thrift_handler.hpp, thrift_main.cpp, thrift_server.cpp, thrift_server.hpp,
> ThriftCalculatorASIOServer.cpp, ThriftMsvcPatchForSvnRev803313.txt,
> ThriftMsvcPatchForSvnRev803313_Rev1.txt.zip,
> ThriftMsvcPatchForSvnRev808166.txt.zip
>
>
> Given the recent discussion on a Windows port and moving to ASIO
> (http://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/200901.mbox/%[email protected]%3e),
> I decided to hack a little Thrift asynchronous prototype server using ASIO
> and here's the result. It implements the Calculator service that can be found
> in the tutorial and, just like TNonblockingServer, it uses a FramedTransport.
> It's just a quick prototype, but I think it's enough for building a more
> generic server/protocol. I've only tested it in Linux, but I think there's
> nothing platform-dependent and can be compiled "as is" in Windows.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
