Repository navigation
Porting select3.go tests. - #1345
Draft
sofiabelen wants to merge 2 commits into
Draft
sofiabelen wants to merge 2 commits into
sofiabelen wants to merge 2 commits into
Conversation
sofiabelen
force-pushed
the
gotests-port
branch
4 times, most recently
from
October 9, 2026 10:22
867057b to
abf2a23
Compare
sofiabelen
force-pushed
the
gotests-port
branch
from
October 11, 2026 15:59
abf2a23 to
7bcc2a2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First time contributor, asking for some guidance
Hello everyone, nice to meet you!
I understand that, given the current situation, maintainers are especially busy these days. That's why I wanted to take a moment to introduce myself before kindly asking for some guidance. I've been learning about EBR and crossbeam, I made a couple of blog posts with my findings. I still have lots to learn before making any meaningful contribution to the project, but I wanted to familiarize myself with the codebase by helping out with porting the remaining go tests. If anyone has a spare moment to help, I'd greatly appreciate it!
I've created this draft-PR with what I've managed so far working with
select3, but I have some questions.As I understand, the goal of porting the go tests is ultimately to verify that, with the help of some wrapping code to make crossbeam channels behave like go's, all the invariants still hold. That said, we are not always testing 1:1 parallels in behavior due to differences in the languages. Why do I write this? Because I'm trying to wrap my head around the fact that there's some "glue" code that makes crossbeam channels behave like go's, and my initial question was: up to which point are we testing this "glue" part vs actual crossbeam behavior. So, this is the assumption with which I've been working with in my mental model, please correct me if I'm wrong.
Question 1: (nil vs closed channel) poisoned mutex
My mental model for closed vs nil channels is:
- closed channels: channel whose senders have all been closed.
- nil channels: in go, it's a pointer to a channel that wasn't initialized (we simulate this behavior by returning
Some(nil_s)/Some(nil_r)when sender/receiver areNone)The question is, when we're testing that 'sending to a closed channel panics', if we do it like this:
we poison the mutex because we're essentially panicking while holding the lock:
The problem is, when trying to reuse the channel for the rest of the test, we can't because the mutex is poisoned.
My workaround was to panic outside of the lock:
I mean, we could also just treat the 'poisoned' channel as unusable. However, from my understanding, in the closed channel doesn't get corrupted if used. My intent was staying faithful to the spirit of the go tests.
Question 2: select! can't be empty
'empty selects always block' -> the select! macro would just not compile if it's empty, so I assume it's safe to leave this test out but clarify with a comment. I mean, the fact that it just doesn't compile is an even stronger mechanism than 'always blocks.' Is this the right approach?
Question 3: nil vs closed channel
Right now, this one blocks because of a similar problem with the nil vs closed channel behavior.
closed_ch_clone.tx()doesn't make a distinction between the case where the sender isNonebecause the channel is closed vs when it's a nil channel.What I came up with is to create a separate
tx_checked:But... none of this looks right. The underlying problem I see is that
Chan<T>has no internal way to differentiating between a nil vs a closed channel. Maybe the best way is to use an enum instead ofOption<Sender<T>>/Option<Receiver<T>>:then,
The problem with this is that it's a more invasive change and would affect other tests.