Linked by Hadrien Grasland on Wed 25th May 2011 05:42 UTC
Thread beginning with comment 474729
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: To continue the old discussion...
by Neolander on Thu 26th May 2011 20:08
in reply to "RE[5]: To continue the old discussion..."
RE[7]: To continue the old discussion...
by Alfman on Thu 26th May 2011 21:47
in reply to "RE[6]: To continue the old discussion..."
"Alright, so 'pure' async is about more than just nonblocking calls for the caller and an event queue for the handler."
That's if we take the concept to it's extreme conclusion, obviously we don't strictly have to. As with anything, there are tradeoffs.
It'd be nice if devs had more experience with async IO models. Many jump to the conclusion that they need MT since it's what they know (and sometimes all that's offered by their platforms - talking to you Java).
I guess we've taken this topic to it's conclusion.
A la prochain fois.




Member since:
2011-01-28
"Async algorithms never use blocking locks ?"
The async model should only ever block when there's no IO to handle. At least in principal, it should never block at any other time.
"But then how do unrelated async drivers synchronize with each other ?"
They can communicate using the same IO mechanisms used elsewhere.
That's just a purist view, in practice it probably wouldn't be a big deal if they infrequently blocked on strictly momentary critical section locks.
Edited 2011-05-26 17:54 UTC