High resolution interval support

[nokute78]

We can pass a argument 'nanoseconds' to flb_input_set_collector_time().
But the value seems not to be used.(Only 'seconds' is used.)

I wrote a patch and it seemed to work.
But I modified some lib/monkey files which come from Monkey project.

# Changed but not updated:
...
#   modified:   ../lib/monkey/mk_core/include/mk_core/mk_event.h
#   modified:   ../lib/monkey/mk_core/mk_event.c
#   modified:   ../lib/monkey/mk_core/mk_event_epoll.c
#   modified:   ../src/flb_engine.c

So, which do you prefer?

1. Pull Request to fluent-bit.
2. Pull Request to Monkey Project. (I have never used , so I can't test it.)
3. Do nothing. Someone will fix. :)

Thanks.

[edsiper]

Interesting feature to enable.

The right way will be to open the PR with http://github.com/monkey/monkey in the GIT master, then I can rebase the changes back here.

note: this change needs to be applied to epoll, kqueue and select backends.

[nokute78]

Thank you for your advice!
So, I will open a Issue and a PR with Monkey project.
I will modify fluent-bit after rebasing from Monkey project.

The resolution depends on timer source.
So I want to make a new API to sleep milliseconds. (it may be difficult to support microseconds in all environment.)

note: this change needs to be applied to epoll, kqueue and select backends.

You mean that I shout modify _mk_event_timeout_create() of
mk_event_epoll.c, mk_event_kqueue.c and mk_event_select.c. right?

[edsiper]

Yes, you are correct, otherwise Fluent Bit on OSX will only support seconds (when compiled for OSX it uses the kqueue backend).

just curious, what's your use case where you need milliseconds ?

[nokute78]

Yes, you are correct, otherwise Fluent Bit on OSX will only support seconds (when compiled for OSX it uses the kqueue backend).

OK.
Thank you for your technical information.

what's your use case where you need milliseconds ?

I think it is helpful to perform accelerated life testing.
To reveal a bug which is taken a long time to reproduce.
Rare timing issue, tiny memory leak which is happened every timer event, and so on.

[edsiper]

I think the it can go beyond that like "real time" collection (not real OS real time but the same approach: low latency).

[nokute78]

I think so, too.
This support will be useful to collect data of some sensors which frequently sense.

Note : I opened a issue at Monkey project.
monkey/monkey#232

[edsiper]

note: @nokute78 already added high resolution support in Monkey core through:

monkey/monkey#232
monkey/monkey#232

I will keep this issue opened until we start v0.8 development to add this high resolution and/or realtime feature.

[nokute78]

Thank you for updating.
I'm waiting for new version.

[edsiper]

merged and compiling. All yours :)

[nokute78]

Congratulations on new release.

I will write a patch using this feature soon.
(But, I have no time on this weekend :( )

Thanks!

[edsiper]

let's keep this issue open, so that feature can be referenced later.

[nokute78]

Sure.

The PR (#59) is used this feature.

[edsiper]

@nokute78 I reviewed the referenced issues and looks like this one is ready to be close, would you please confirm ?

[nokute78]

@edsiper Sure. I will close this one.