cannot use int(srv.listenerFile.Fd()) (type int) as type syscall.Handle in function

[ngmoco]

cannot use int(srv.listenerFile.Fd()) (type int) as type syscall.Handle in function

[dgrijalva]

I haven't tried to install on windows. I'll poke at that tonight and see what I can do.

I think I have windows somewhere ...

-dave

On Mar 29, 2012, at 8:48 PM, Guillermo [email protected] wrote:

Captain we've been hit!

Tried to install.

go get github.com/ngmoco/falcore

And got:

# github.com/ngmoco/falcore
C:\Go\src\pkg\github.com\ngmoco\falcore\server.go:68: cannot use int(srv.listenerFile.Fd()) (type int) as type syscall.Handle in function
argument

Windows amd64 Go 1

---

Reply to this email directly or view it on GitHub:
#4

[phrozen]

Thanx Dave. Is not like I'm expecting a fix soon, I just happened to be on
Windows when I saw the announce and tried to installed it and, well, that
happens. It's pretty nice you're working on doing falcore platform
independent.

On Thu, Mar 29, 2012 at 9:52 PM, Dave Grijalva <
[email protected]

wrote:

I haven't tried to install on windows. I'll poke at that tonight and see
what I can do.

I think I have windows somewhere ...

-dave

On Mar 29, 2012, at 8:48 PM, Guillermo [email protected]
wrote:

Captain we've been hit!

Tried to install.

go get github.com/ngmoco/falcore

And got:

# github.com/ngmoco/falcore
C:\Go\src\pkg\github.com\ngmoco\falcore\server.go:68: cannot use
int(srv.listenerFile.Fd()) (type int) as type syscall.Handle in function
argument

Windows amd64 Go 1

---

Reply to this email directly or view it on GitHub:
#4

---

Reply to this email directly or view it on GitHub:
#4 (comment)

"No le digas a Dios lo grande de tu tormenta, mejor dile a tu tormenta lo
grande de tu Dios."

[dgrijalva]

I don't know how safely I can fix this one. I haven't programmed for Windows in year. Anyone have a patch?

@smw1218 I can't remember the reason we needed the listener to be non-blocking. I think it might not be necessary with the new timeout behavior in go1.

[dgrijalva]

Testing indicates syscall.SetNonblock is still required for hot restart.

The Issue:
syscall.SetNonblock is defined on windows, but it requires syscall.Handle instead of int. syscall.Handle is only available on windows. It's basically impossible to get that call to compile without supplying different code per platform. Luckily, all the nonblock stuff is only really needed for the hot restart functionality. Since that relies on fork, we can't use it on windows anyway.

The Fix:
I gave up on using server_$GOOS.go files since I couldn't figure that out nor find adequate documentation. Instead, I use the reflect package to call syscall.SetNonblock only if the runtime version expects an int as the first argument. That allowed everything to compile, but the server still wouldn't start on windows. Turns out asking a socket for it's descriptor on windows returns an error. We didn't need that anyway, so I just wrapped the whole section in a condition on runtime.GOOS.

The Result:
Hot restart still works on supported OSs. Falcore servers run on Windows minus the hot restart behavior. Windows users of the world owe Dave a beer.

[smw1218]

Looks like I'm late to the party. Thanks Dave for rocking this! As far as hot restart goes, it looks like there would have to be some good cooperation from the go libs to support it:

http://stackoverflow.com/questions/670891/is-there-a-way-for-multiple-processes-to-share-a-listening-socket

If someone really needs the hot restart on windows, I'll find some time to look into it.