Skip to content

Conversation

craigcomstock
Copy link
Contributor

@craigcomstock craigcomstock commented Jul 26, 2024

ret = pthread_cancel(thread_data.thread);
#else
ret = pthread_kill(thread_data.thread, SIGUSR2);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@larsewi you had mentioned in my previous PR comment

Is it safe to join a "killed" thread? Will this call the signal handler installed by the agent. If so, is this fine? Also the man pthread_kill(3) says:

And so here I am using the downstream patch which sends a kill signal and adds a signal handler to which then calls pthread_exit which is the "other option" of how the joined thread could be terminated at the appropriate timeout moment.

After a canceled thread has terminated, a join with that thread
using pthread_join(3) obtains PTHREAD_CANCELED as the thread's
exit status. (Joining with a thread is the only way to know that
cancelation has completed.)

from https://www.man7.org/linux/man-pages/man3/pthread_cancel.3.html

@craigcomstock
Copy link
Contributor Author

@xtkoba, I took your patch at https://github.com/termux/termux-packages/blob/master/packages/cfengine/pthread_cancel.patch as inspiration to improve my earlier attempt.

I am also working on a "cfengine: Bump 3.24.0" PR. Getting this patch upstream will have to wait for 3.24.1 release if we merge the PR here.

Copy link
Contributor

@vpodzime vpodzime left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The cherry-picked lines mention commits that are not in this repository. I don't think we need them. And let's squash the commits, please. The first one is not good enough alone.

sigemptyset(&actions.sa_mask);
actions.sa_flags = 0;
actions.sa_handler = ThreadSignalHandler;
sigaction(SIGUSR2, &actions, NULL);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer SIGHUP or some other signal that semantically matches the case? In fact, I think we should block many common signals in the new thread, we don't want handlers for SIGINT etc. to be handled in it. So I'd extend this to something like what we do in cf-reactor and used one of the other signals here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I agree with SIGHUP/etc.

The reason for splitting commits was to acknowledge and make clear the use of another persons contribution.

I do agree that it makes more sense to have commits which are sufficient and complete on their own but also recognize that sometimes we make "mistakes" in a commit and then have to come back and fix them, sort of like in this case here.

larsewi
larsewi previously approved these changes Jul 29, 2024
@craigcomstock
Copy link
Contributor Author

The cherry-picked lines mention commits that are not in this repository. I don't think we need them. And let's squash the commits, please. The first one is not good enough alone.

Actually the "cherry-picked" comments are not needed, these are simply commits and not cherry-picked from someplace permanent or interesting (just another branch or my forked repo so an artifact of git operations). I will remove the cherry-pick comments and consider squashing after I fixup the signal handling.

@craigcomstock craigcomstock marked this pull request as draft July 29, 2024 18:07
@craigcomstock
Copy link
Contributor Author

This is a work-in-progress now as I am refactoring a few things based on code review. No need to comment until I un-draft the PR.

@vpodzime
Copy link
Contributor

This is a work-in-progress now as I am refactoring a few things based on code review. No need to comment until I un-draft the PR.

Thanks for the notice and double thanks for the refactoring!

Android/Termux doesn't have pthread_cancel so use pthred_kill instead

Ticket: CFE-4401
Changelog: title
(cherry picked from commit ebd52a29238122c4bcc2f86d2313f9f4a258243c)
(cherry picked from commit 1e965d3)
AC_CHECK_FUNCS apparently doesn't take into account the __ANDROID_API__ level properly and so incorrectly determines that copy_file_range is available for termux at API 24 but copy_file_range is <= 34.

Ticket: none
Changelog: none
Copy link

Marking this PR as stale due to inactivity; it will be closed in 7 days.

@github-actions github-actions bot added the stale Pull requests with no recent activity label May 26, 2025
@craigcomstock
Copy link
Contributor Author

yeah, won't get to this in 7 days so will close and keep my branch for a future PR.

@craigcomstock craigcomstock deleted the CFE-4401-2/master branch May 27, 2025 15:44
@craigcomstock craigcomstock restored the CFE-4401-2/master branch May 27, 2025 15:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Pull requests with no recent activity
Development

Successfully merging this pull request may close these issues.

3 participants