 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
On Thu, 03 Sep 2009 10:38:49 -0400 Jeffrey Hutzelman <jhutz at cmu.edu> wrote:> There is another model: > >> > while (1) { > gss_process_events(&minor, ...); >> > >> > ret = gss_call(&minor, GSS_C_NOWAIT, ...); >> > if (ret != 0 && minor == EAGAIN) { >> > continue; >> > } >> > ... >> > break; >> > } That's not another model. That's equivalent to using the synchronous form of the call, if gss_process_events() blocks until the mech is ready to be called, or to polling, if it eventually times out.But there only needs to be one caller of gss_process_events for any number of NOWAIT calls. So you can build event loops with it.
No, you really can't. Sure, if your goal is to establish six contexts simultaneously and then go on to something else, you can do that. But if your goal is to establish one context while still allowing PalmOS to interact with the user, this doesn't cut it. In fact, that's not entirely fair, because in that model you can't have threads _or_ asynchronous callbacks -- the library's only choice would be to send the application an event when its ready for another call. But the point still holds -- if you give me an interface that blocks until it's ready, then I can't run my own event loop, and if you give me an interface that I have to poll, then I'm polling, not running an event loop.
A proper event loop blocks until there is an event (_any_ event), then does some work. Polling is not an event loop. Polling wastes cycles and can result in serious increases in power use besides. Not to mention all of the points Nico has made with respect to the complexities of an API trying to impose an event model on an application with several intermediate libraries in between.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu> Carnegie Mellon University - Pittsburgh, PA