On Wed, May 16, 2018 at 8:07 PM, Juliusz Chroboczek <j...@irif.fr> wrote:
>
> I'm interfacing with a C library that expects to do its own I/O, but
> wants to be called after a file descriptor is ready for read. My code
> currently looks roughly like this:
>
> var fdset syscall.FdSet
> var bits = unsafe.Sizeof(fdset.Bits[0]) * 8
> fdset.Bits[uintptr(fd)/bits] |= (1 << (fd % bits))
> var ctv C.struct_timeval
> C.gettimeout(&ctv)
> tv := syscall.Timeval{int64(ctv.tv_sec), int64(ctv.tv_usec)}
> n, err := syscall.Select(int(fd + 1), &fdset, nil, nil, &tv)
> if n < 0 {
> return err
> }
> rc, err := C.dostuff(fd)
> if(rc < 0) {
> return err
> }
>
> I'm bothered by two things:
>
> - the way I access the syscall.FdSet feels like an unportable hack;
> - I'd much rather hook into Go's scheduler then burn a thread on
> sleeping in select.
>
> Is the above the correct way to interface with the C library, or is
> there a better way?
If you do this in Go, you should use golang.org/x/sys/unix package
rather than the syscall package. But since you have to call C anyhow,
I would suggest just doing it in C.
There isn't any way to hook into Go's scheduler for this. Go's
scheduler provides no mechanism for waiting for data without reading
the data.
Ian
--
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.
For more options, visit https://groups.google.com/d/optout.
