Re: Another defer reference

mån 2006-08-07 klockan 19:24 +0800 skrev Steven:

> If you let the defer function call commDeferFD, you don't run through the
> comm loop 2 times to cause a FD to back off (once to set the defer/backoff
> flag, and once to actually back off). The code in the comm loop is there
> as a fail-safe, but is not the most optimal solution.

But the defer function is only called from there..

how could the number of loops differ if it's the defer function calling
commDeferFD or if it's the only caller which does this automatically
when the defer function indicates the fd should be deferred?

The current flow is

1. FD is registered for read

2. I/O event arrives

3. Defer function defers the FD when called from the comm loop while
processing read events.

4. FD stays deferred, not touched by the comm loop again until kicked
alive.

And what I propose would give a very similar flow

1. FD is registered for read

2. I/O event arrives

3. If the defer function says the FD should be deferred then defer it
from the comm loop while processing read events.

4. FD stays deferred, not touched by the comm loop again until kicked
alive.

Regards
Henrik