@cmuratori @jhaberstro @handmade_hero I just like to point out how often people get new surprises, so people look at my less funny!
-
-
Replying to @cmuratori
@cmuratori@jhaberstro@handmade_hero But either way, the _right_ way to do a lock with CFG is to try the lock first, then call the OS!1 reply 0 retweets 0 likes -
Replying to @cmuratori
@cmuratori@jhaberstro@handmade_hero You don't do it the other way around _anyway_. That way there'd be no problem using CFG.1 reply 0 retweets 0 likes -
Replying to @cmuratori
@cmuratori@jhaberstro@handmade_hero Because you wouldn't ever hit the CFG slow path until you were already going to go to sleep anyway.1 reply 0 retweets 0 likes -
Replying to @cmuratori
@cmuratori@jhaberstro@handmade_hero So it's still the CRT's fault regardless.1 reply 0 retweets 1 like -
Replying to @cmuratori
@cmuratori@handmade_hero Heh, fair enough. Just thought it curious that you mentioned std::atomic, but the post was about std::mutex.1 reply 0 retweets 0 likes -
Replying to @jhaberstro
@cmuratori@handmade_hero Wasn't sure if I was missing something!1 reply 0 retweets 0 likes -
Replying to @jhaberstro
@jhaberstro@handmade_hero It's std::anything, really. I trust none of it :)1 reply 0 retweets 2 likes -
Replying to @cmuratori
@cmuratori@handmade_hero Ever looked into std::async? That one is a nightmare. (In C++11 at least; not sure if C++14 improved it at all)1 reply 0 retweets 0 likes -
Replying to @jhaberstro
@jhaberstro@handmade_hero I never look at anything in std anymore. I know it is either wrong or will be wrong eventually...1 reply 0 retweets 2 likes
@cmuratori @jhaberstro @handmade_hero ... and I seem to consistently be proven right on that front :)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.