Events
"이희승 (Trustin Lee)"
trustin at gmail.com
Mon Jun 8 00:21:25 EDT 2009
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.
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.
>> callLater() with no delay is pretty simple to implement. I wonder how
>> Twisted Matrix implements delayed event triggering though. Netty has a
>> HashedWheelTimer which is dedicated to delayed task execution, and you
>> can do whatever you want with it.
>
> 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(). 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.
Thanks for an interesting idea,
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/2a8a021d/attachment.bin
More information about the netty-users
mailing list