Re: [Libevent-users] [libevent-usr] When is a [regular file descriptor] readable or writable?

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 <william@xxxxxxxxxxxxxxxxxx>

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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users in the body.