I realized that using UV_RUN_DEFALUT is suitable for apps that doesn't care
about performance too much. Just do the work 🤷
The meaning of work is a definition by your self. For example handling
request can be a work, or updating some internal states of app....
I defined my work flow like this:
1. reading callback just place the arrived data in buffer. Nothing else.
2. When the loop ran just once, in an idle function, retrieve the buffers
and sessions and handle the request.
So, Work for me is handling request, and when there is no request, there is
no work to do.
I implement loop running like this:
if(sessions_count=0)
uv_run(UV_RUN_DEFALUT);
else {
// Start the idle handle and...
uv_run(UV_RUN_NOWAIT);
}
I know that it is complicated 🤣, you can use prepare handle as well. Loop
does waiting when there is a prepare handle in it's list.
On Mon, Apr 5, 2021, 17:25 Nick Thompson <nctho...@gmail.com> wrote:
> Hm, interesting, that does make sense, thanks for the reply!
>
> If I'm using uv_run with UV_RUN_DEFAULT, how can I get in there to sleep?
> And how do I determine if there's no real work to do?
>
> On Monday, April 5, 2021 at 8:48:09 AM UTC-4 rezam...@gmail.com wrote:
>
>> Well.... I think you are right 🧐
>>
>> But consider this: when there is a idle handle in a loop, the loop don't
>> wait for other handles. Just check them for any event. It doesn't
>> block-and-wait. I think you have to implement some criteria to sleep the
>> process when there is no real work to do.
>>
>>
>> On Mon, Apr 5, 2021, 16:46 Nick Thompson <ncth...@gmail.com> wrote:
>>
>>>
>>> Hi,
>>>
>>> After my previous thread here, I started exploring other potential
>>> patterns for my project. I think the Idler pattern presented in the
>>> Utilities docs (
>>> http://docs.libuv.org/en/v1.x/guide/utilities.html#idler-pattern) would
>>> work well for my app, so I sketched it up briefly with my loop running with
>>> UV_RUN_DEFAULT.
>>>
>>> I'm finding that if I call `uv_idle_start` even with a dummy callback,
>>> my app will spin up to 90-100% CPU immediately. If I never call that start,
>>> I'm at 0-1% (and of course just running the default loop). On profiling, it
>>> looks like my app spends a ton of energy going back and forth between
>>> uv__run_check and uv__io_poll.
>>>
>>> Is there some gotcha to this pattern that I should be aware of? Or
>>> something particular I need to do to set it up correctly?
>>>
>>> Thanks,
>>> Nick
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "libuv" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to libuv+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/libuv/e9e2ed9e-477d-4386-9305-74d5333f26edn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/libuv/e9e2ed9e-477d-4386-9305-74d5333f26edn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "libuv" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to libuv+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/libuv/b50176b1-fb10-47da-bf39-fdf924f8256bn%40googlegroups.com
> <https://groups.google.com/d/msgid/libuv/b50176b1-fb10-47da-bf39-fdf924f8256bn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to libuv+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/libuv/CAMLQwnkm0ObqM-LirA_wZK9FpytxQBCZj2b%3Dh_wmZ9hNbZn1hg%40mail.gmail.com.
