Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

coap_io: do not call select() for contexts without sockets on Windows #1599

Merged
merged 1 commit into from
Mar 12, 2025

Conversation

mkicherer
Copy link
Contributor

Hello,

in a NodeJS environment, my wrapper library for libcoap maintains the list of created contexts and provides a loop() function that will call coap_io_process with every context and COAP_IO_NO_WAIT every few milliseconds (as we do not have threads or proper access to the internal event loop). If I create an "empty" context without sessions or endpoints early on while this loop is running, we see errors from the select() call in coap_io.c if we start this application on Windows. In this application, we start client sessions in this context later on certain events.

After comparing the documentation for select() on Windows [1] and Linux [2], it looks to me like the Windows version does not like being called without file descriptors/sockets. I applied this patch and it seems to work without error messages so far.

I could add code in my wrapper to call coap_io_process only for contexts with active sockets but I think this patch might also benefit others. Maybe it would even make sense to skip more code in this function if the context has no sockets. What do you think?

Thank you!

[1] https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-select
[2] https://man7.org/linux/man-pages/man2/select.2.html

@mrdeep1
Copy link
Collaborator

mrdeep1 commented Mar 11, 2025

It is also true that even if there are endpoints / sessions associated with a context, it is conceivable (but very unlikely) that there is nothing that is in a read /write / except state.

I'm not so sure about skipping more code as there are some subsequent timeout checks, and the time spent in the function should always be reported (even if it is 0 milli-secs).

@mrdeep1 mrdeep1 merged commit 45006ae into obgm:develop Mar 12, 2025
31 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants