thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Craig (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (THRIFT-1690) Sockets and Pipe Handles truncated on Win64
Date Tue, 13 Nov 2012 20:48:13 GMT

    [ 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

Mime
View raw message