[
https://issues.apache.org/jira/browse/THRIFT-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13496527#comment-13496527
]
Ben Craig commented on THRIFT-1690:
-----------------------------------
The old code was a bit of a portability mess. The new code is a different
portability mess. The toy program that I've been using for my own testing has
gotten away without needing to touch the raw HANDLE / file descriptor. I would
prefer to solve most use cases in that way, but still provide access to the
underlying OS object when platform specific things are needed. I think #ifdefs
are inevitable there. There is still significant room to improve though. I
don't think IntPtr is the answer though, as that is too large on 64-bit *nix
platforms.
The projects I am working on care a lot about named pipes and named AF_UNIX
sockets. This is for Mac, Windows, and Linux, both 32 and 64-bit. I am
actively working on making it easy to use these in cross-platform code. I hope
to have patches for the following problems in the next month:
1. Portable naming. I want to be able to construct my TTransport (or
TServerTransport) without ifdefs. That means that "MyPipe" needs to have the
appropriate slashes added on Windows (already done). It also means that
"MyPipe" needs to either be put in a special folder on *nix, or needs to be an
abstract socket. Putting the socket file in the app's current working
directory probably isn't desirable.
2. Better cleanup. Stop doesn't currently work on TPipeServer. Stopping
AF_UNIX sockets doesn't clean up the file (and I'm not sure it can safely).
Both of these cases are important to me, because my use cases aren't of the
"launch the app and let it run 2 years" variety. My clients and servers start
and stop in interactive scenarios.
I don't have a personal need / interest in anonymous pipes. I wasn't trying to
break them, but I also didn't have tests for them. I think the correct way to
handle these is to have a new TServerTransport class specifically for anonymous
pipes. It may forward to TPipeServer and TServerSocket, but it can have the
constructors that make sense for anonymous pipes, and not carry the baggage of
named pipes.
For the record, I'm not thrilled with the "multi-purpose" transports like
TSocket, TPipe, and their server counterparts. Porting single aspects of those
classes is normally easy, but porting all of the aspects often doesn't work.
My preferred approach would have involved TTCPSocket, TNamedSocket(?),
TAnonymousSocket, and the like. A lot of them would have similar
implementations (possibly forwarding to helper classes), but it would make for
more portable client code.
> Sockets and Pipe Handles truncated on Win64
> -------------------------------------------
>
> Key: THRIFT-1690
> URL: https://issues.apache.org/jira/browse/THRIFT-1690
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.9
> Environment: 64-bit Windows
> Reporter: Ben Craig
> Assignee: Roger Meier
> Attachments: lib_socket_typedef.patch, libthrift_pipe_size.patch,
> libthrift_warning_purge.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> On 64-bit Windows, "int" is a 32-bit value. SOCKET and HANDLE are 64-bit.
> All of the files dealing with sockets in thrift use "int" as the type of a
> socket, as this is the idiomatic way to handle sockets on POSIX systems. For
> portability, a SOCKET typedef is probably needed.
> For the Pipe Server and Pipe Transport, HANDLEs are cast to ints to store as
> member variables for some reason (maybe to avoid #including <windows.h> in a
> header?).
> Both of these situations can result in invalid handles being used (and valid
> handles being leaked) when the system is under load.
--
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
