[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: thread cancellation, take 2
From: |
Ludovic Courtès |
Subject: |
Re: thread cancellation, take 2 |
Date: |
Sun, 23 Sep 2007 12:42:43 +0200 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) |
Hi Julian,
"Julian Graham" <address@hidden> writes:
> Alright -- I think I've got it working. After mucking about for a bit
> with asyncs, I realized that it makes more sense to evaluate cleanup
> handlers in do_thread_exit -- and evaluation should happen there
> anyway, since pthreads says cleanup handlers get called when the
> thread exits for any reason, not just cancellation. Duh.
Good!
> The patch I've attached adds three new public functions:
> cancel-thread, push-thread-cleanup, and pop-thread-cleanup. API
> documentation on their behavior is included in the changes.
Thinking a bit more about it, maybe we could let users handle the list
of handlers if needed. That is, we'd have just
`set-thread-cleanup-procedure!' (a two-argument procedure whose first
arg is a thread) and `thread-cleanup-procedure' (a one-argument
procedure); users who have cleanup code spread over several procedure
would provide a procedure that iterates over such pieces of code. That
would keep Guile's built-in mechanisms minimal.
What do you think?
> I've never submitted a patch for Guile before, so I've likely made a
> few mistakes in formatting, etc., and I don't really know the vetting
> procedure. I hope I've gotten the main bits right, though. Please let
> me know if there are any changes I should make.
First, you'll need to assign copyright to the FSF so that we can
incorporate your changes (I'll send you the relevant stuff off-line).
Then, you need to make sure your code follows the GNU Standards as much
as possible (a few comments follow). Also, please add a few test cases
to `threads.test' that exercise the new API.
I think the patch adds a useful feature so, unless someone raises an
objection, I'd be OK to apply it to HEAD when you're done with the
copyright paperwork.
> +static SCM handle_cleanup_handler(void *cont, SCM tag, SCM args) {
> + *((int *) cont) = 0;
> + return scm_handle_by_message_noexit(NULL, tag, args);
> + return SCM_UNDEFINED;
> +}
The second `return' is superfluous. Also, for clarity and consistency
with the GCS, the function should rather read:
static SCM
cleanup_handler_error_handler (void *cont, SCM tag, SCM args)
{
int *continue_p = (int *) cont;
*continue_p = 0;
return scm_handle_by_message_noexit (NULL, tag, args);
}
But if you agree with the change I suggested above (removing the list of
handlers), you no longer need that function: you can just use
`scm_handle_by_message_noexit ()' directly.
> + while(!scm_is_eq(t->cleanup_handlers, SCM_EOL))
> + {
> + int cont = 1;
> + SCM ptr = SCM_CAR(t->cleanup_handlers);
> + t->cleanup_handlers = SCM_CDR(t->cleanup_handlers);
Please add a whitespace before opening parentheses.
> +SCM_DEFINE (scm_cancel_thread, "cancel-thread", 1, 0, 0,
> + (SCM thread),
> +"Asynchronously force the target @var{thread} to terminate. @var{thread} "
> +"cannot be the current thread, and if @var{thread} has already terminated or
> "
> +"been signaled to terminate, this function is a no-op.")
Better indent the doc string.
Thanks,
Ludovic.
- thread cancellation, take 2, Julian Graham, 2007/09/20
- Re: thread cancellation, take 2, Ludovic Courtès, 2007/09/20
- Re: thread cancellation, take 2, Julian Graham, 2007/09/20
- Re: thread cancellation, take 2, Julian Graham, 2007/09/23
- Re: thread cancellation, take 2,
Ludovic Courtès <=
- Re: thread cancellation, take 2, Julian Graham, 2007/09/23
- Re: thread cancellation, take 2, Ludovic Courtès, 2007/09/24
- Re: thread cancellation, take 2, Julian Graham, 2007/09/24
- Re: thread cancellation, take 2, Julian Graham, 2007/09/24
- Re: thread cancellation, take 2, Ludovic Courtès, 2007/09/26
- Re: thread cancellation, take 2, Julian Graham, 2007/09/26