Re: [capnproto] Fine grained control over event queue

[Rowan Reeve]

Hi again Kenton,

Thank you for your valuable input. Yes, agreed that it's a bit precarious 
but it'd be a useful stop-gap that is currently tested and working for us, 
albeit with a much rougher self-maintained patch.

For more context about our situation: we're constrained by a large existing 
software stack running on an embedded system that has been extended to use 
capnp for some IPC but still assumes a single real-time thread. The system 
configuration is such that that the main thread runs on its own dedicated 
physical core to meet some bandwidth requirements for I/O over Ethernet, 
and introducing another loop or thread could negatively impact that (locks 
on shared buffers or message passing). We'd need quite some time to 
investigate, test and benchmark any changes in that direction.

I will be raising a PR on GitHub later today with the first solution 
(optionally limiting event loop turns on poll) similar to the previously 
linked pastebin and you can see how you feel about it whenever you find 
time to review.


Thanks,

Rowan Reeve



On Wednesday, June 22, 2022 at 10:01:07 PM UTC+2 ken...@cloudflare.com 
wrote:

> Hi Rowan,
>
> Hmm, this feels to me like more of a use case for threads or signal 
> handlers. Trying to limit processing time by limiting turn count seems 
> precarious to me as the amount of time spent on any turn could vary wildly.
>
> That said the change you propose seems not too bad and I'd accept it, I 
> just worry it's the tip of the iceberg here. Like will you find out that 
> some particular callbacks in the RPC system can be especially expensive, 
> and need to be counted as multiple turns? I think that would be going to 
> far.
>
> If by any chance your synchronous processing could be made safe to run in 
> a signal handler (requires using lockless data structures), I think a timer 
> signal could be a pretty neat solution here.
>
> -Kenton
>
> On Wed, Jun 22, 2022 at 2:17 PM Rowan Reeve  wrote:
>
>> Hi Kenton,
>>
>> Our company is attempting to use Cap'n Proto in a soft-realtime system 
>> where we need tight control over the resolution of promises. Our problem is 
>> that we have some existing synchronous processing which needs to run 
>> frequently and timely (on the order of 100 microseconds) but our system 
>> must also service incoming RPCs (which might access results of said 
>> processing) without missing a single processing window.
>>
>> What we would like to be able to do roughly corresponds the below 
>> pseudocode inside our server:
>>
>> loop forever:
>>   if before synchronous processing window:
>> poll single event
>>   else:
>> do synchronous processing
>>
>> *WaitScope::poll* almost fulfills our needs, but it causes all new 
>> events since the last poll to be picked up and their corresponding promises 
>> to be resolved, in this case to incoming requests, which can occasionally 
>> cause us to miss our window. Our individual RPC functions are relatively 
>> short-lived, but when receiving many in a short span of time, we encounter 
>> this timing issue.
>>
>> I think what we're looking for is an overload to *WaitScope::poll* 
>> limiting the turn count:
>> https://pastebin.com/T4eFM60F
>>
>> Your thoughts? Otherwise could this be something that might be accepted 
>> as a small pull request?
>>
>> Useful details:
>>
>>- C++ 17 with official capnp/kj library
>>- Linux 5.x kernel (so UnixEventPort as async provider)
>>
>>
>>
>> Rowan Reeve
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Cap'n Proto" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to capnproto+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/capnproto/17eba638-4bbe-49fe-a270-c5e40b40b967n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to capnproto+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/capnproto/fe46595c-47ab-4bab-b6fe-1387bdde68a1n%40googlegroups.com.

Re: [capnproto] Fine grained control over event queue

['Kenton Varda' via Cap'n Proto]

Hi Rowan,

Hmm, this feels to me like more of a use case for threads or signal
handlers. Trying to limit processing time by limiting turn count seems
precarious to me as the amount of time spent on any turn could vary wildly.

That said the change you propose seems not too bad and I'd accept it, I
just worry it's the tip of the iceberg here. Like will you find out that
some particular callbacks in the RPC system can be especially expensive,
and need to be counted as multiple turns? I think that would be going to
far.

If by any chance your synchronous processing could be made safe to run in a
signal handler (requires using lockless data structures), I think a timer
signal could be a pretty neat solution here.

-Kenton

On Wed, Jun 22, 2022 at 2:17 PM Rowan Reeve  wrote:

> Hi Kenton,
>
> Our company is attempting to use Cap'n Proto in a soft-realtime system
> where we need tight control over the resolution of promises. Our problem is
> that we have some existing synchronous processing which needs to run
> frequently and timely (on the order of 100 microseconds) but our system
> must also service incoming RPCs (which might access results of said
> processing) without missing a single processing window.
>
> What we would like to be able to do roughly corresponds the below
> pseudocode inside our server:
>
> loop forever:
>   if before synchronous processing window:
> poll single event
>   else:
> do synchronous processing
>
> *WaitScope::poll* almost fulfills our needs, but it causes all new events
> since the last poll to be picked up and their corresponding promises to be
> resolved, in this case to incoming requests, which can occasionally cause
> us to miss our window. Our individual RPC functions are relatively
> short-lived, but when receiving many in a short span of time, we encounter
> this timing issue.
>
> I think what we're looking for is an overload to *WaitScope::poll*
> limiting the turn count:
> https://pastebin.com/T4eFM60F
>
> Your thoughts? Otherwise could this be something that might be accepted as
> a small pull request?
>
> Useful details:
>
>- C++ 17 with official capnp/kj library
>- Linux 5.x kernel (so UnixEventPort as async provider)
>
>
>
> Rowan Reeve
>
> --
> You received this message because you are subscribed to the Google Groups
> "Cap'n Proto" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to capnproto+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/capnproto/17eba638-4bbe-49fe-a270-c5e40b40b967n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to capnproto+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/capnproto/CAJouXQnK9rdh7Zv2y0RWT70zhBJkc8WEZeESqRn_Qz1o%2B3RR-g%40mail.gmail.com.

[capnproto] Fine grained control over event queue

[Rowan Reeve]

Hi Kenton,

Our company is attempting to use Cap'n Proto in a soft-realtime system 
where we need tight control over the resolution of promises. Our problem is 
that we have some existing synchronous processing which needs to run 
frequently and timely (on the order of 100 microseconds) but our system 
must also service incoming RPCs (which might access results of said 
processing) without missing a single processing window.

What we would like to be able to do roughly corresponds the below 
pseudocode inside our server:

loop forever:
  if before synchronous processing window:
poll single event
  else:
do synchronous processing

*WaitScope::poll* almost fulfills our needs, but it causes all new events 
since the last poll to be picked up and their corresponding promises to be 
resolved, in this case to incoming requests, which can occasionally cause 
us to miss our window. Our individual RPC functions are relatively 
short-lived, but when receiving many in a short span of time, we encounter 
this timing issue.

I think what we're looking for is an overload to *WaitScope::poll* limiting 
the turn count:
https://pastebin.com/T4eFM60F

Your thoughts? Otherwise could this be something that might be accepted as 
a small pull request?

Useful details:

   - C++ 17 with official capnp/kj library
   - Linux 5.x kernel (so UnixEventPort as async provider)



Rowan Reeve

-- 
You received this message because you are subscribed to the Google Groups 
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to capnproto+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/capnproto/17eba638-4bbe-49fe-a270-c5e40b40b967n%40googlegroups.com.