Conversation
|
pew.. this predefined macro stuff is... tedious.. |
31cf98e to
b87afa4
Compare
|
gotta say: msvc? not inspiring.
|
|
@azat this should be it "programming in 2 minute chunks over the course of a week" |
azat
left a comment
There was a problem hiding this comment.
Sorry for the delay, please take a look at the comments.
signal.c
Outdated
| intptr_t comparand = *p; | ||
| do { | ||
| x = comparand; | ||
| if (sizeof(*p) == 8) |
There was a problem hiding this comment.
Better to detect this at configuration time (cmake/autotools):
signal.c
Outdated
| do { | ||
| x = comparand; | ||
| if (sizeof(*p) == 8) | ||
| comparand = _InterlockedCompareExchange64(p, x, comparand); |
There was a problem hiding this comment.
Can this (including loop) be replaced with _InterlockedCompareExchange(p, 0, 0) ?
P.S. for x86_64 we don't even need to use atomic_store and can simply use volatile, but to keep thins more reliable, I'm suggesting this.
There was a problem hiding this comment.
the default ordering for atomic_ operations is "sequentially consistent" to ensure consistent behaviour when protecting locks (from acquire to release).
it's probably fine to go without but it shouldn't be called atomic_load anymore.
imo, the "proper" solution is to add an abstraction that ensures at least "relaxed" ordering.
it would be implemented using atomic_ or _Interlocked and the atomic_ variant would just be slight overkill.
There was a problem hiding this comment.
It will be great to avoid overhead here, since then, we may consider using it to resolve #777 (it is more hot place than this one)
Are you willing to make proper primitives or it is better to merge this as-is?
|
By the way, this is very willing patch! |
05329c9 to
01984c0
Compare
|
i've had a meal, slept for a few hours, had another meal, brought a car to the mechanic, walked back, ate more, and these checks still aren't done :-D |
Sadly, but we are using public workers, and it seems that there is one global pool for project, so one queue for all pull requests and master branch. |
Fixes libevent#779. Signed-off-by: Harvey Tuch <htuch@google.com>
|
no problem - i just thought it to be funny 😛 i'm pushing my changes to event.c and so into this branch. unrelated: issue with gitignore? |
2a5eba1 to
e98bbc5
Compare
e98bbc5 to
e0cd6e0
Compare
|
@azat accidental close? |
|
Ugh, sorry, that was about a comment not the issue. |
|
I would love to preserve all the discussion but github does not allow to reopen if you force pushed to the branch. Sigh. |
building on #1105, implement a workaround for incomplete stdatomics support on windows