On Tue, Dec 04, 2018 at 12:29:03PM -0800, apmat...@gmail.com wrote:

> My problem is following: I need to use windows WSAAccept() instead of 
> normal accept (net package seems to use AcceptEx).
> 
> I'm I missing somethig 
> 
> I do not know a way to extend net-package so only way I know is to use 
> reflect to get the listener Sysfd (I know .. really bad, other options ?) 
> and pass it to WSAAccept().
> 
> Now I get the new handle/fd back and to be able to use rest of the code I 
> would need to convert it to net.conn, how can I do this ?

I think you can call net.TCPListener.SyscallConn() to get the syscall.RawConn
giving you access to the underlying handle.

The problem is: what would you want to do next?
I mean, it will be possible to not call Accept* on the listener and pass the
handle you will fetch from the raw connection to WSAAccept(), but then what
would you do with the handle of the "accepted" socket it will produce?
IIRC, net.FileConn, which is supposed to "wrap" an FD into a Go-native
"object" is not supported on Windows.

> In general, how can we extend net package when all important structures are 
> private ? fd_windows.go:netFD struct includes poll.FD what is even deeper 
> at package chain.

You cannot, but Go is F/OSS, so if there's really no other way to do what you
are after, you can carry a patch or a patch series on top of the branch of the
Go release you're using and use it to build your code.
Sure, this implies you do this for an in-house project but the stated problem
appears to be a really weird one and hence suggests that this is the case.

Still, can you explain what is the real reason for using WSAAccept?
I'm asking to make sure we're not dealing with a so-called "XY Problem".

Since some time the net package in the Go standard library gained the ability
to get a grip on the underlying connection/endpoint FD/handle (partially
explained above) so if you need to set some funky options on the connection,
you can do this w/o resorting to using a different Win32 API call to accept
connections on it.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20220713171245.6i2ztxdkyptxry54%40carbon.

Reply via email to