On Tue, 10 Jun 2008 17:08:30 -0600
Mike Heath <[EMAIL PROTECTED]> wrote:
> Julien Vermillard wrote:
>
>
> > The polled is here because it's base classes for transport
> > implementations using event strategy based on system calls behaving
> > like poll() (which can be in fact poll, epoll, kqueue
Julien Vermillard wrote:
The polled is here because it's base classes for transport
implementations using event strategy based on system calls behaving like
poll() (which can be in fact poll, epoll, kqueue or select depending
of the JVM/OS configuration).
Those class aren't "polling" in a loop
I propose
- AbstractEventIo(Acceptor/Connector/..)
- AbstractSelectIo(Acceptor/Connector/..)
- AbstractAsyncIo(Acceptor/Connector/..)
Sorry, my previous mail was partial,
I +1 the three proposals.
even the Io could be removed.
We can keep the Io to characterize the type of Event, Selec
On Jun 10, 2008, at 6:44 AM, Julien Vermillard wrote:
I propose
- AbstractEventIo(Acceptor/Connector/..)
- AbstractSelectIo(Acceptor/Connector/..)
- AbstractAsyncIo(Acceptor/Connector/..)
even the Io could be removed.
WDYT ?
+1
-pete
--
(peter.royal|osi)@pobox.com - http://fotap.org/~osi
Julien Vermillard wrote:
Hi,
- AbstractSelectIo(Acceptor/Connector/..)
This one sounds the best to me, as select() resonates with the java
Selector class.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
sounds good to me.
On Tue, Jun 10, 2008 at 9:44 AM, Julien Vermillard
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> as Emmanuel stated, the AbstractPollingIoXXX class are badly named.
>
> The polled is here because it's base classes for transport
> implementations using event strategy based on system call
Hi,
as Emmanuel stated, the AbstractPollingIoXXX class are badly named.
The polled is here because it's base classes for transport
implementations using event strategy based on system calls behaving like
poll() (which can be in fact poll, epoll, kqueue or select depending
of the JVM/OS configurat
