| Summary: | _ReadWriteBarrier is deprecated, use atomic_thread_fence instead | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Coriiander <coriiander> |
| Component: | atomic | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED WONTFIX | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | don't know | ||
| Hardware: | All | ||
| OS: | Windows (All) | ||
|
Description
Coriiander
2018-06-09 04:37:56 UTC
SDL is a C library, are there equivalent mechanisms for C libraries? Sorry, to be clear, SDL supports building without any C runtime to avoid C runtime issues on Windows. Is there a way to use atomic_thread_fence in this configuration? (In reply to Sam Lantinga from comment #2) > Sorry, to be clear, SDL supports building without any C runtime to avoid C > runtime issues on Windows. Is there a way to use atomic_thread_fence in this > configuration? Yes, that's clear and a core value for SDL. Unfortuntely I don't know of a Microsoft-provided replacement for the deprecated APIs for C. It is an evergrowing problem with the provided Microsoft APIs, as in they're moving evermore away from providing usable C-interfaces. Alternatives would be: - keep using deprecated intrinsics; - use build-time opt-in C++ implementation with custom public C interface; - use generic fallback logic; - provide architecture-specific assembler implementations (probably a no go); As I cannot bring in a solution, I perhaps should not have filed the ticket. It's just that building forth upon deprecated matter feels wrong. I agree. It sounds like for now, continuing to use the intrinsics is our best option. Feel free to reopen this bug if you have more ideas. |