Skip to content

Conversation

@thejpster
Copy link
Member

An alternative signal implementation using AtomicUsize.

@gmmyung
Copy link
Contributor

gmmyung commented Feb 9, 2024

The recommended approach for libraries is to leave it up to the end user whether or not to enable this feature. (However, it may make sense to enable this feature by default for libraries specific to a platform where other implementations are known not to work.)

The portable-atomic crate advises to leave out cas implementation for unsupported tagets.

@thejpster
Copy link
Member Author

If we left it to the end user binary to enable the cs feature on portable atomic we'd need a binary in the tree to do a test build. Or we could add a flag for test build purposes I guess. Or we could just not build for those targets.

@gmmyung
Copy link
Contributor

gmmyung commented Feb 9, 2024

What about adding a critical-section feature? The --all-features will make it available during test builds.

@thejpster
Copy link
Member Author

What about adding a critical-section feature? The --all-features will make it available during test builds.

Good idea! Done. Have also serialised the tests.

eldruin
eldruin approved these changes Feb 19, 2024
Copy link
Member

@eldruin eldruin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, could you add an entry to the changelog about this?

@thejpster
Copy link
Member Author

Adding this to today's todo pile.

@thejpster thejpster force-pushed the signals-with-atomics branch from ebc0b53 to d889219 Compare March 17, 2024 10:48
@thejpster thejpster merged commit 3b6d9e9 into master Mar 17, 2024
@eldruin eldruin deleted the signals-with-atomics branch March 18, 2024 08:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants