Re[2]: Nanosecond timestamps for ev_stat

Roman Tsisyk roman at tarantool.org
Wed May 13 09:13:20 CEST 2015


Wednesday, May 13, 2015 5:34 AM +02:00 from Marc Lehmann <schmorp at schmorp.de>:
> On Tue, May 12, 2015 at 05:59:33PM +0300, Roman Tsisyk <roman at tarantool.org> wrote:
> > I made a patch to add support for nanosecond timestamps in ev_stat.
> > Please review and consider to merge.
> 
> Hi, thanks for the patch, but I am afraid it isn't so simple.
> 
> While providing nanosecond resulitioon if possible is one of our goals, too,
> we haven't found a way to make it possible.
> 
> Simply making the ev_stat internal test a bit more sensitive without being
> able to tell the user of ev_stat does not allow the libev user to make active
> use of this feature - the user still has to assumer there is only the
> standard one second resolution, both because that might be the actual
> filesystem resolution, and libev might not have tested this at all.
>
> To put it differently - the libev user has to cope with one second
> resolution, whether libev was compiled to compare nanoseconds or not.

Nanosecond resolution is now standardized by POSIX.1-2008.

I need this fix only to make inotify implementation in libev to be more interactive.
My application follows an open file and do some business logic as soon as new bytes appended.
It would be nice to eliminate one second delays in the ev_stat watchers.
`struct stat' members are not interested at all.

>
> Also, the detection for the struct member availability should work without
> autoconf, at least in most cases, and there would need to be a way to signal
> this to the libev users.

I can try check _POSIX_C_SOURCE >= 200809L || _XOPEN_SOURCE >= 700 instead.
However, stat.st_timensec member can be available without these definition and I doesn't found any reliable #define to check that.
BTW, memcmp() for struct stat on all systems (except NetBSD) is also enough to fix my problem. 

-- 
WBR,
   Roman Tsisyk <roman at tarantool.org>
   http://tarantool.org/ - an efficient in-memory data store and a Lua application server


More information about the libev mailing list