A change was integrated for the topic “Fix handles starting from zero (Bug #16814)”. https://gitlab.xfce.org/xfce/tumbler/-/commit/f8e6f17dc3abddf9886a68b661c282e407fdebc1 The variable “handle” became an unsigned integer in the function “tumbler_scheduler_request_new”. This data type provides support for the computation functionality “wraparound”. I find that this design choice contains a risk as long as it is not checked if previous request identifiers became reusable again. (The concrete life time of managed data processing objects is unknown.) Thus I suggest to consider additional software design options. 1. Terminate the program after the zero handle was detected again so that duplicate assignments of request identifiers can generally not happen. 2. Introduce a dynamic tracking for assigned requests by configurable data structures according to system preferences in a run time environment.
Do you really think that the handle will wraparound and tumbler will be still serving request with identifier 1?
(In reply to Ali Abdallah from comment #1) I find that such a possibility exists for the current data processing approach generally. I suggest to take more concerns into account for the circumstances under which specific request handles can become problematic.
(In reply to Markus Elfring from comment #2) > (In reply to Ali Abdallah from comment #1) > I find that such a possibility exists for the current data processing > approach generally. > I suggest to take more concerns into account for the circumstances under > which specific request handles can become problematic. I don't agree, such possibility does not exist at all, you can try to prove me wrong if you wish, with a test case, all what you have to do is to generate 4,294,967,295 requests, so the handle wraps, while still serving request with handle number 1.
(In reply to Ali Abdallah from comment #3) We have got different views for possibilities. The corresponding probabilities can look unlikely. I imagine that memory errors could also trigger the use of the one request handle in undesirable ways. Can such concerns affect the desired software correctness?
(In reply to Markus Elfring from comment #4) > (In reply to Ali Abdallah from comment #3) > We have got different views for possibilities. > The corresponding probabilities can look unlikely. > > I imagine that memory errors could also trigger the use of the one request > handle in undesirable ways. > > Can such concerns affect the desired software correctness? We don't write safety critical software here, and in any case, memory errors will typically bring down the whole OS much before causing errors on the request handle of tumbler...
(In reply to Ali Abdallah from comment #5) > We don't write safety critical software here, I find such a view interesting and questionable. > and in any case, memory errors will typically bring down the whole OS much Should such a view be also reconsidered? > before causing errors on the request handle of tumbler... I propose to improve the error detection for this use case.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/tumbler/-/issues/25. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev