As more followup... I would suggest running a timer per thread. I assume every thread would contain some type of event-trigger loop, and I would make your timer calls in that loop, caching for the remainder of that iteration. I'm not quite sure how well this would work, but you can most certainly get away with a fair bit of drift, especially if high-precision timers are not required for log output.
-Aaron On Mon, Jun 15, 2009 at 11:32 AM, Aaron Wiebe<[email protected]> wrote: > I went over your post... > > You shouldn't be seeing a 4ms response time on a gettimeofday() call - > this is my test: > > gettimeofday({1245079355, 445434}, NULL) = 0 <0.000004> > gettimeofday({1245079355, 445503}, NULL) = 0 <0.000004> > gettimeofday({1245079355, 445560}, NULL) = 0 <0.000003> > gettimeofday({1245079355, 445629}, NULL) = 0 <0.000004> > > That's 3-4 microseconds. > > For the sake of argument, I checked time() as well, which is obsoleted > by gettimeofday()... > > ime(NULL) = 1245079501 <0.000008> > time(NULL) = 1245079501 <0.000007> > time(NULL) = 1245079501 <0.000004> > time(NULL) = 1245079501 <0.000008> > time(NULL) = 1245079501 <0.000004> > > About half the speed, but still in the microsecond range. > > gettimeofday() is one of the fastest syscalls you can issue. > Obviously you don't want to beat on it, but I wouldn't worry about > calling it a few dozen times per second. > > -Aaron > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
