From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: thread cancellation, take 2
Date: Sun, 23 Sep 2007 12:42:43 +0200 [thread overview]
Message-ID: <87vea1oe70.fsf@chbouib.org> (raw)
In-Reply-To: 2bc5f8210709222216rf7aa8ednd380fa8db2975073@mail.gmail.com
Hi Julian,
"Julian Graham" <joolean@gmail.com> 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.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2007-09-23 10:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-20 14:30 thread cancellation, take 2 Julian Graham
2007-09-20 15:18 ` Ludovic Courtès
2007-09-20 15:36 ` Julian Graham
2007-09-23 5:16 ` Julian Graham
2007-09-23 10:42 ` Ludovic Courtès [this message]
2007-09-23 18:39 ` Julian Graham
2007-09-24 11:42 ` Ludovic Courtès
2007-09-24 15:39 ` Julian Graham
2007-09-24 20:17 ` Julian Graham
2007-09-26 4:03 ` Ludovic Courtès
2007-09-27 2:39 ` Julian Graham
2007-10-18 0:41 ` Julian Graham
2007-10-20 11:12 ` Ludovic Courtès
2007-10-20 13:02 ` Ludovic Courtès
2007-10-20 22:19 ` Julian Graham
2007-10-21 13:03 ` Ludovic Courtès
2007-10-21 13:11 ` Ludovic Courtès
2007-10-23 14:16 ` Julian Graham
2007-10-24 2:35 ` Julian Graham
2007-10-29 22:04 ` Ludovic Courtès
2007-10-29 22:20 ` Julian Graham
2007-10-29 23:23 ` Neil Jerram
2007-10-30 9:35 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vea1oe70.fsf@chbouib.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).