Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

mu.lock: after acquiring m.ch, why does the re-check only look at closed and not ctx?

Abierto
  • ¿Algo no está bien?
#573 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
go
Área
networking

Línea de trabajo

Comienza en conn.go, alrededor de mu.lock en la línea 286, y sigue cómo sus contextos y canales cerrados son utilizados por los llamadores. Compara el comportamiento de la cancelación y de la adquisición del lock, y determina después si el caso reportado requiere un cambio en el código o en la documentación; se considera terminado cuando la pregunta del issue queda respondida con una justificación reproducible.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Hi, I was looking at mu.lock and had a question about this part:

func (m *mu) lock(ctx context.Context) error {
	select {
	case <-m.c.closed:
		return net.ErrClosed
	case <-ctx.Done():
		return fmt.Errorf("failed to acquire lock: %w", ctx.Err())
	case m.ch <- struct{}{}:
		// To make sure the connection is certainly alive.
		// As it's possible the send on m.ch was selected
		// over the receive on closed.
		select {
		case <-m.c.closed:
			// Make sure to release.
			m.unlock()
			return net.ErrClosed
		default:
		}
		return nil
	}
}

After acquiring the lock, closed is checked again in case both branches were ready.

Why isn't ctx.Done() checked here as well?

Could ctx be canceled right after m.ch is selected, causing lock to return nil while holding the lock with an already-canceled context?

Lenguaje dominante
Go
Estrellas
5.5k
Forks
379
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de coder/websocket

Todos los issues de coder/websocket

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.