Events

["이희승 (Trustin Lee)"]

On 08-Jun-2009 14:11, Yang Zhang wrote:
> 이희승 (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.

Could you elaborate on why a recursive event call is a problem?  I guess
I'm missing out something.

>>> 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.

I agree that select/epoll/... can be used to implement application
timeout by specifying poll timeout (Selector.select(long timeout) in Java).

JDK 7 AIO allows you to specify read/write timeout, but I'm not sure if
it's related with application event timeout scheduling:

  * http://tinyurl.com/njh6l6

BTW, I think you are mixing two issues - recursive calls and timeouts.
Non-recursive calls can be achieved without timeouts and vice versa.  Is
there any reason they need to be implemented in a tightly coupled manner?

Thanks,
Trustin

-- 
— Trustin Lee, http://gleamynode.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20090608/b62f033d/attachment.bin