Linked by Hadrien Grasland on Fri 27th May 2011 11:34 UTC
Permalink for comment 474808
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/24/13 17:26 UTC
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
More Features »
Sponsored Links



Member since:
2010-05-06
Particularly in the case of a semaphore or mutex.
One function of blocking is to give up the CPU when you can't do anything, and to queue for a resource.
It would turn simple code into something like the following, but the pastabilities are endless:
gotit=0;
waitforit() { gotit=1 }
func() {
...
getit(resource,waitforit);
while(!gotit) sched_yield; // heat-up, drain battery,etc.
Of course there might not be callbacks, but check-if-done functions,
while( !areWeThereYet(destination) ) burn();
Of course if it is truly asynchronous, the callback function will have a parameter specifying the callback which needs to be called when the first callback is completed.
I could live without blocking, but I could also live in a post-apocalyptic world as well, but it wouldn't be any more easy, simple, or pleasant.