unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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


  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).