Hi, William
Thanks for your quotation. It's really helpful and provide official
proof of Andrew's opinion. I'll check it out further.
Thanks for reply.
Harvey
2011/8/4 William Ahern <will...@25thandclement.com>
> On Wed, Aug 03, 2011 at 03:39:34PM +0800, zhihua che wrote:
> > Hi, everyone,
> >
> > I'm reading libevent-2.0 code and have made certain progress:).
> However,
> > I'm still confused with some basic concepts like "ready" for reading or
> > writing. In the context of sockets, I think I can imagine this "ready"
> > situation: the socket is ready for reading when the receiving buffer
> > receives some data from the lower level of the network stack, and is
> ready
> > for writing when the sending buffer has enough free space to accept data
> > from the higher level.
> > My point here is how it works in terms of regular file, like local
> disk
> > regular file. Imagine I was monitoring a local regular file descriptor. I
> > can't figure out what actions or conditions can cause the descriptor
> > readable or writable.
> >
>
> POSIX mandates that regular files always return ready for reading or
> writing. IEEE Std 1003.1-2008 says, regarding the poll() interface, that
>
> Regular files shall always poll TRUE for reading and writing.
>
> For select(),
>
> File descriptors associated with regular files shall always select
> true for ready to read, ready to write, and error conditions.
>
> The reasons for this are based on historical and modern implementations
> (neither the BSDs nor Linux have an asynchronous block layer), but
> regardless it's a part of the abstract interface and won't change anytime
> soon even if the implementations change in a way that supports non-blocking
> reads. AIO in Linux, for example, AFAIK, is still done using threads,
> either
> preemptible userland threads or kernel work queue threads.
>
> ***********************************************************************
> To unsubscribe, send an e-mail to majord...@freehaven.net with
> unsubscribe libevent-users in the body.
>
