Talk:Event loop

Computing Start‑class

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Start	This article has been rated as Start-class on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.

This is the talk page for discussing improvements to the Event loop article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Isn't all this polling causing a lot of wasted CPU usage? --Abdull 14:15, 15 April 2007 (UTC)[reply]

No, the central select (or poll) call is blocking. –EdC 16:06, 15 April 2007 (UTC)[reply]

And blocking (computing) doesn't cause wasted CPU usage? --Abdull 15:49, 19 April 2007 (UTC)[reply]

Certainly not; the kernel will suspend the task until the status of the file descriptor(s) changes or an event occurs. –EdC 21:40, 19 April 2007 (UTC)[reply]

Thank you very much for your answers! --Abdull 20:59, 22 April 2007 (UTC)[reply]

preemptive vs cooperative

In the usage section, I edited a misleading distinction made between cooperative and preemptive models. It was wrongly stated that under the cooperative model getnextmessage() would not block. This is not generally true, the usual case is that it would block. The difference is that under the cooperative model, if the process fails to promptly call the getnextmessage() or yield() it can freeze the whole system. This does not however imply that preemptive systems are more efficient. Choppingmall (talk) 04:28, 3 February 2008 (UTC)[reply]