¿Es posible esperar en ambos canales y descriptores de archivos al mismo tiempo en Go?

Question

Sé que puedo esperar en múltiples canales usando la sintaxis select {} en Ir, y espero múltiples descriptores de archivos usando syscall.Select() o funciones similares. ¿Pero es posible esperar en ambos canales a la vez?

Para el fondo, quiero tener una rutina que acepte mensajes a través de un canal y los envíe a través de una conexión de socket (proporcionada por gozmq), mientras que simultáneamente espera respuestas en la conexión de socket.

Debido a los requisitos de seguridad de subprocesos de la biblioteca subyacente, solo se puede acceder al socket en un subproceso a la vez, por lo que me preguntaba si hay una forma de manejar esto desde una única rutina.

Answer 1

La selección de un canal y un descriptor de archivo no es posible porque las abstracciones se encuentran en niveles diferentes. Los canales son manejados por el runtime go y los descriptores de archivos por el sistema operativo. Lo que necesita es hacer un puente entre ellos y esto se puede hacer con un net.Pipe().

bastante más de lo que tiene que hacer es dedicar un goroutine a epoll()/select() para ver sus ZMQ de enchufe y un solo "despertar" net.Pipe(). Este es tu servidor de encuestas. Otro goroutine escucha en sus canales de lectura y escritura. Cuando alguien envía los canales de lectura o escritura, el segundo goroutine enviaría el conducto para despertar al servidor de encuestas.

Así es como funciona el paquete de red en la biblioteca estándar. Recomiendo leerlo en busca de inspiración (o robar ... la licencia BSD es muy liberal).

Aquí está una descripción de pollServer from net. Puede que necesite leer el código para entender lo que dice, pero esta sección de fd.go debería ser un buen lugar para empezar a buscar.

// A pollServer helps FDs determine when to retry a non-blocking 
// read or write after they get EAGAIN. When an FD needs to wait, 
// send the fd on s.cr (for a read) or s.cw (for a write) to pass the 
// request to the poll server. Then receive on fd.cr/fd.cw. 
// When the pollServer finds that i/o on FD should be possible 
// again, it will send fd on fd.cr/fd.cw to wake any waiting processes. 
// This protocol is implemented as s.WaitRead() and s.WaitWrite(). 
// 
// There is one subtlety: when sending on s.cr/s.cw, the 
// poll server is probably in a system call, waiting for an fd 
// to become ready. It's not looking at the request channels. 
// To resolve this, the poll server waits not just on the FDs it has 
// been given but also its own pipe. After sending on the 
// buffered channel s.cr/s.cw, WaitRead/WaitWrite writes a 
// byte to the pipe, causing the pollServer's poll system call to 
// return. In response to the pipe being readable, the pollServer 
// re-polls its request channels. 
// 
// Note that the ordering is "send request" and then "wake up server". 
// If the operations were reversed, there would be a race: the poll 
// server might wake up and look at the request channel, see that it 
// was empty, and go back to sleep, all before the requester managed 
// to send the request. Because the send must complete before the wakeup, 
// the request channel must be buffered. A buffer of size 1 is sufficient 
// for any request load. If many processes are trying to submit requests, 
// one will succeed, the pollServer will read the request, and then the 
// channel will be empty for the next process's request. A larger buffer 
// might help batch requests. 
// 
// To avoid races in closing, all fd operations are locked and 
// refcounted. when netFD.Close() is called, it calls syscall.Shutdown 
// and sets a closing flag. Only when the last reference is removed 
// will the fd be closed. 

Good luck re-implementation net. La buena noticia al final de todo esto es que tu zmq-socket estará seguro para hilos en el momento.

Answer 2

Se puede acceder a todas las net.Conn's in Go al mismo tiempo. Si su biblioteca se basa en eso, no debería haber ningún problema.

De lo contrario, es bastante común en Ir a spawn one goroutine por conexión. Esta rutina a menudo solo es responsable de leer desde el socket (que puede bloquear) y reenviar todos los datos a otra rutina de coordinación utilizando un canal. Este coordinador goroutine puede interactuar con todas esas conexiones de socket (que están envueltas en un canal) y otros eventos usando una instrucción select. También tenga en cuenta que puede agregar fácilmente un búfer a esos canales, de modo que un cliente lento no pueda bloquear su rutina de coordinación.

Answer 3

Genere una nueva rutina para cada fd que desee esperar, pídales que envíen fd a un canal cuando lean algo, seleccione en los canales.