[
https://issues.apache.org/jira/browse/THRIFT-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591906#comment-13591906
]
Peace C edited comment on THRIFT-1870 at 3/4/13 12:12 AM:
----------------------------------------------------------
I agree it's unfortunate how domain sockets sitting on the filesystem causes
platform-specific issues. I would prefer TServerSocket to automatically remove
the domain socket on its close(), but not sure if that's kosher. It seems that
if the server dies, there's no reason to keep it around and the clients can
handle any exceptions caused by its removal. That's should be discussed in the
context of TServerSocket though and not TPipe[Server].
I've not considered abstract pipes on Linux. That's a good idea that merits
implementing. Perhaps another #ifdef for Linux platforms, or maybe add a new
constructor that creates an abstract pipe? It could automatically prepend a
NULL to the pipename. Platform-specific ugliness is best tucked away in the
transport.
At some point I'll make some time to implement *NIX anonymous pipes if someone
else hasn't gotten to it already. For us, passing a pipe handle to a child
process is a security feature since only the parent & child can use it. That
hasn't been a requirement for our application yet but I could see that changing
at a moment's notice.
I'm glad that you've been putting the transport through its paces and reported
those issues. I'll try to work on patches for them as time permits unless you
already have something in hand.
was (Author: peace):
I agree it's unfortunate how domain sockets sitting on the filesystem
causes platform-specific issues. I would prefer TServerSocket to automatically
remove the domain socket on its close(), but not sure if that's kosher. It
seems that if the server dies, there's no reason to keep it around and the
clients can handle any exceptions caused by its removal. That's an that should
be discussed for TServerSocket though and not TPipe[Server].
I've not considered abstract pipes on Linux. That's a good idea that merits
implementing. Perhaps another #ifdef for Linux platforms, or maybe add a new
constructor that creates an abstract pipe? It could automatically prepend a
NULL to the pipename. Platform-specific ugliness is best tucked away in the
transport.
At some point I'll make some time to implement *NIX anonymous pipes if someone
else hasn't gotten to it already. For us, passing a pipe handle to a child
process is a security feature since only the parent & child can use it. That
hasn't been a requirement for our application yet but I could see that changing
at a moment's notice.
I'm glad that you've been putting the transport through its paces and reported
those issues. I'll try to work on patches for them as time permits unless you
already have something in hand.
> Enhance TPipe / TPipeServer transport to support both Windows 64-bit and
> cross-platform *NIX support
> ----------------------------------------------------------------------------------------------------
>
> Key: THRIFT-1870
> URL: https://issues.apache.org/jira/browse/THRIFT-1870
> Project: Thrift
> Issue Type: Improvement
> Affects Versions: 0.9
> Environment: Windows, *NIX
> Reporter: Peace C
> Fix For: 0.9
>
> Attachments: TPipe_64bit_xplatform.patch
>
>
> This patch adds support for Windows 64-bit builds by using std::ptrdiff_t to
> represent Windows' pipe HANDLE. It also restores cross-platform *NIX support
> that was broken in THRIFT-1690.
> See contrib/transport-sample for a working cross-platform example of how to
> use TPipe[Server]. I tested all permutations of Win32/64-bit clients with
> Win32/64-bit servers and they were happy. Also tested successfully on OSX.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
