Timer (interval) and threads

[ibc]

The README clearly says that just a single thread is used, however it does not clarify whether the underlying usrsctp-neat just uses (or can use) a single thread or whether rawrtc-data-channel hides the multi-thread design of usrsctp-neat and exposes a single-thread API to the app.

Also, why does rawrtc-data-channel requires that the app initializes it with a timer_handler callback in which the app must _"Start a timer that calls rawrtcdc_timer_tick every interval milliseconds"_? Would not make more sense if rawrtc-data-channel knew when it must ask the sctp stack again so it can expose an API (similar to DTLSv1_get_timeout() in OpenSSL) for the app to set a timer at that specific timeout and query rawrtc-data-channel for pending stuff within timer callback?

Probably usrsctp-neat does not expose such an API so it cannot be done. However that would be proper way to go for integrating into a loop, right?.

[lgrahl]

Well, actually, no thread is used. It's driven by whatever thread you call it with. Do you think this section of the FAQ is not clear enough?

Does it create threads?

No. However, there is an issue with the usrsctp dependency which will hopefully be resolved soon.

Last time I checked there was some thread idling (but it doesn't do any harm). Could be that this has been fixed.

Probably usrsctp-neat does not expose such an API so it cannot be done. However that would be proper way to go for integrating into a loop, right?.

Right. But it's not in my hands. :woman_shrugging:

[ibc]

Yes, it's clear that it does not create threads. I failed to figure out that the timer_handler callback tells the app to run its own timer :)

[ibc]

BTW: do you consider (or have tested) whether polling rawrtcdc_timer_tick() every 10ms behaves performant?

[saurik]

Is there a reason you are using usrsctp-neat instead of the actual upstream usrsctp? The fork you are using is well over 600 commits behind the actual source of this library (which is terrifying from the perspective of a C library that might have random buffer overflows). I noticed this when following the link to see the "issue with the usrsctp dependency", was shocked that it had been open since 2018 with no response given that usrsctp is an actively maintained codebase, and then was like "wait, this isn't the real usrsctp repository :(".

[lgrahl]

Not sure what you mean. #34 was merged a long time ago. :slightly_smiling_face: I'll update the readme.

[lgrahl]

The "timer tick" could be more sophisticated but that isn't in my hands. I guess this can be closed then.