unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Gregory Marton <gremio@csail.mit.edu>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: bug-guile@gnu.org
Subject: Re: with-timeout and asynchronous alarm (was: signal handling different in 1.8.3 than 1.8.1?)
Date: Fri, 18 Jul 2008 09:44:31 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0807180928580.27704@ashmore.csail.mit.edu> (raw)
In-Reply-To: <87ljzzbdtb.fsf@gnu.org>

Hi Ludo',

Sorry for reading more into your words than was intended.

> At a minimum, we could provide a Scheme primitive to allow users to 
> explicitly ask system asyncs to run (and that's just a few lines of C to 
> add).  What do you think?

If it's easy, a "force-asyncs" may be useful in general.  I worry first 
that it is a sort of representation exposure, and that the promise (they'll 
get run very soon) should be good enough.  More importantly, short of a 
busy-wait loop, I don't see how it would help the alarm case.  Where would 
I invoke it?

The common case is something like
    (with-timeout 60 (lambda () (http-get "http://some.url/"))
                     (lambda () (throw 'server-timeout)))
which boils down to
    (alarm 60)
    (block-waiting-for-input inet-port)
which in testing I chose to simulate as:
    (alarm 60)
    (sleep 100)

In both the blocking and the sleep case, even a busy wait feels like it 
would want to run in a separate thread or something, constantly calling 
force-asyncs.  In the blocking case, perhaps there are games to play with 
select but that forces the code to be timed out to cooperate.  If someone 
didn't write their library with this in mind...

I haven't written much multithreaded code, and none in guile, so I'm 
probably misunderstanding something.  How would force-asyncs help?

Many thanks,
Grem

> Hi,
>
> Gregory Marton <gremio@csail.mit.edu> writes:
>
>>> As I suggested earlier [0], I think it's just a matter of
>>> non-determinism: there's no guarantee as to when system asyncs are run.
>>
>> And as I suggested earlier, I think it is very valuable to have
>> guarantees about when alarms in particular are handled -- that being
>> what they're for.
>
> Yes, I understand the rationale---and sorry if my message sounded harsh!
>
> At a minimum, we could provide a Scheme primitive to allow users to
> explicitly ask system asyncs to run (and that's just a few lines of C to
> add).  What do you think?
>
> Ludo'.
>
>
>
>

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)    A programming language is a very dangerous data structure.
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~





      reply	other threads:[~2008-07-18 13:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-01 19:35 signal handling different in 1.8.3 than 1.8.1? Gregory Marton
2008-06-03 15:07 ` Ludovic Courtès
2008-06-03 16:05   ` Gregory Marton
2008-06-03 20:32     ` Ludovic Courtès
2008-06-06 19:37       ` Gregory Marton
2008-06-06 19:56         ` Gregory Marton
2008-06-07 10:38           ` Ludovic Courtès
     [not found]             ` <Pine.LNX.4.64.0806260936100.31255@ashmore.csail.mit.edu>
     [not found]               ` <87bq1ngvw7.fsf@gnu.org>
2008-06-27 19:05                 ` Gregory Marton
2008-06-28 18:09                   ` Ludovic Courtès
2008-06-29 17:45                     ` Gregory Marton
2008-06-29 18:02                       ` Gregory Marton
2008-06-29 18:06                         ` Gregory Marton
2008-06-30  7:38                           ` Ludovic Courtès
2008-07-07  0:30                             ` Gregory Marton
2008-07-07  8:57                               ` Ludovic Courtès
2008-07-17 12:08                                 ` Gregory Marton
2008-07-17 12:37                                   ` Ludovic Courtès
2008-07-17 15:24                                     ` Gregory Marton
2008-07-17 15:51                                       ` Ludovic Courtès
2008-07-17 15:59                                         ` Gregory Marton
2008-07-17 20:47                                           ` Neil Jerram
2008-07-17 22:11                                             ` Gregory Marton
2008-07-18  8:18                                               ` Ludovic Courtès
2008-07-18 11:23                                                 ` Gregory Marton
2008-07-18 12:02                                                   ` Ludovic Courtès
2008-07-18 13:44                                                     ` Gregory Marton [this message]

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=Pine.LNX.4.64.0807180928580.27704@ashmore.csail.mit.edu \
    --to=gremio@csail.mit.edu \
    --cc=bug-guile@gnu.org \
    --cc=ludo@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).