Events

[Yang Zhang]

이희승 (Trustin Lee) wrote:
> On 07-Jun-2009 16:46, Yang Zhang wrote:
>> Hi,
>>
>> 이희승 (Trustin Lee) wrote:
>>> You can issue a new event by calling Channels.fireXXX(...),
>>> ChannelPipeline.sendUpstream/Downstream(...), or
>>> ChannelHandlerContext.sendUpstream/Downstream(...).  However, the call
>>> is made recursively.
>> The fact that the call is made recursively is problematic: the code
>> immediately following the async call is expected to immediately execute
>> (at least, before the callback is executed), but with the recursive
>> call, the callback will execute *in the same thread and before* the code
>> immediately following the call.
> 
> In asynchronous I/O, you can't make any assumption on when and how an
> asynchronous request will be executed.  The point of the asynchronous
> I/O is, IMHO, it returns as quickly as possible, possibly before the
> request is processed.

It's fine for the async IO to complete before the request is processed 
(since, as you notice, you have no control over the timing), but the 
problem here is that it's firing recursively within the same event call 
stack.

> 
> Unless there's an explicit use case that causes StackOverflowError in a
> real world application, I'm not sure I need to modify the current behavior.

>> The blocking syscall (e.g. select) made at the core of any asynchronous
>> IO framework comes with a timeout parameter, which the framework can use
>> for asynchronous sleeps.  The framework manages a priority queue of
>> "sleep" events, and wakes them up at the appropriate times using this
>> timeout mechanism.
> 
> This is only true when you use select().

Or poll, or epoll, or kqueue (kevent()), or asio (asio_suspend()), or....

> You can't make such an
> assumption either because Netty API is not necessarily supposed to use
> selector API only.  For example, a new Netty transport can be
> implemented with old blocking I/O and JDK 7 asynchronous I/O API, and
> therefore it's not a viable option to integrate the timeout feature into
> the core out of the box.

With blocking IO, you use a separate thread per blocking event (in this 
case, delays) - so again, the callback would not need to fire 
recursively in the same call stack.

I'm unfamiliar with the JDK7 API, but I would be surprised if it did not 
have timeouts as well.

> 
> Thanks for an interesting idea,
> Trustin

FWIW, most other async IO frameworks I've worked with do provide 
asynchronous timeouts:

- C/C++
   - ACE
   - Boost.Asio
   - libevent
- Java
   - SEDA
- Python
   - Twisted
-- 
Yang Zhang
http://www.mit.edu/~y_z/