Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

`Buffer<'_>` shouldn't be `Send`

Ouverte
#347 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
À clarifier
Activité
Calme
Stack technique
rust

Piste de recherche

Commencez par suivre les API Buffer et Surface autour de next_buffer(), en vous concentrant sur la manière dont la présentation est liée au transfert entre threads et au verrouillage de la plateforme. Comparez la justification Android dans softbuffer PR #331 et évaluez le comportement existant de Send et Sync ; le travail est considéré comme terminé lorsqu’une décision claire a été prise concernant le contrat de sécurité des threads de Buffer et qu’elle a été documentée ou implémentée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug DS - Android NDK

Android holds a lock on the buffer while it's in use, see https://github.com/rust-windowing/softbuffer/pull/331, and I'm experimenting a bit with a similar design on macOS (which is to say, I think it's a reasonable thing for our buffers to do).

MutexGuards are not Send though, which makes me wonder if this is sound?

Is there a use-case for Buffer<'_> being Send? As-in, is there ever a case where you would want to present on a different thread than the one that called next_buffer()? The problem wouldn't exist if you moved the entire Surface to a different thread.

I can see the argument for buffers being Sync though (&mut T is Sync), it could maybe make sense to pass the buffer to a scoped thread and render in that.

Langage dominant
Rust
Étoiles
506
Forks
84
Métriques de merge des PR
Aucune PR mergée en 30 j

Préparer son environnement

Nous n'avons pas encore vérifié les fichiers d'installation de ce projet. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de rust-windowing/softbuffer

Toutes les issues de rust-windowing/softbuffer

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.