signal handling different in 1.8.3 than 1.8.1?

signal handling different in 1.8.3 than 1.8.1?

[Gregory Marton]

Hi folks,

Now that I've upgraded to 1.8.3 from 1.8.1, some old test cases are 
failing.  In particular:

(define (ensure body-lambda ensuring-lambda)
    (dynamic-wind
        (lambda () #t)
        body-lambda
        ensuring-lambda))

(define (with-sigaction signum handler flags lamb)
      (let ((old-sigaction (sigaction signum)))
        (if flags (sigaction signum handler flags) (sigaction signum handler))
        (ensure
         lamb
         (lambda ()
           (sigaction signum (car old-sigaction) (cdr old-sigaction))))))

;; imagine an appropriate (assert bool message) and (assert-equal a b msg)

(let ((orig (sigaction SIGALRM))
        (sigcalled #f))
     (with-sigaction
      SIGALRM (lambda (sig) (set! sigcalled #t)) #f (lambda () (raise SIGALRM)))
     (assert sigcalled "we set and handled an alarm")) ;; FAILS in 1.8.3
     (assert-equal orig (sigaction SIGALRM) "returned to the original state")
     (let ((outer "nop")
           (inner "nop"))
       (with-sigaction
           SIGALRM (lambda (sig) (set! outer "outer")) #f
           (lambda ()
             (with-sigaction
              SIGALRM (lambda (sig) (set! inner "inner")) #f
              (lambda ()
                (raise SIGALRM)))
             (raise SIGALRM)))
       (and (assert-equal "inner" inner "inner sig got handled") ;; FAILS
            (assert-equal "outer" outer "outer sig got handled")))
     (assert-equal orig (sigaction SIGALRM) "returned to the original state")

All of these passed in 1.8.1.  If this is no longer The Recommended Way, 
how would one go about it?

Many thanks,
Grem

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)          Lots of Insidious Silly Parentheses (LISP :-)
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~

Re: signal handling different in 1.8.3 than 1.8.1?

[Ludovic Courtès]

Hi,

Gregory Marton <gremio@csail.mit.edu> writes:

> Now that I've upgraded to 1.8.3 from 1.8.1, some old test cases are
> failing.  In particular:

According to `NEWS', there were no signal-related changes.

> (define (ensure body-lambda ensuring-lambda)
>    (dynamic-wind
>        (lambda () #t)
>        body-lambda
>        ensuring-lambda))
>
> (define (with-sigaction signum handler flags lamb)
>      (let ((old-sigaction (sigaction signum)))
>        (if flags (sigaction signum handler flags) (sigaction signum handler))
>        (ensure
>         lamb
>         (lambda ()
>           (sigaction signum (car old-sigaction) (cdr old-sigaction))))))

Signal handlers are invoked asynchronously as system asyncs, and system
asyncs are run whenever `SCM_TICK' is encountered in the C code.

There doesn't seem to be any Scheme procedure to force the execution of
system asyncs, but maybe you can try invoking LAMB above in
`call-with-unblocked-asyncs' and/or adding a `(sleep 0)' right before it
to force the execution of pending system asyncs.

Let us know if it helps.

Thanks,
Ludovic.

Re: signal handling different in 1.8.3 than 1.8.1?

[Gregory Marton]

Hi Ludovic,

> The following message is a courtesy copy of an article
> that has been posted to gmane.lisp.guile.bugs as well.

Is bug-guile@gnu.org now out of date?   I may have to get a newsreader. 
Are they mirrored?


>> Now that I've upgraded to 1.8.3 from 1.8.1, some old test cases are
>> failing.  In particular:
>
> According to `NEWS', there were no signal-related changes.

Nevertheless, it has consistently passed in 1.8.1 and consistently fails in 
1.8.3 with no other changes.


>> (define (ensure body-lambda ensuring-lambda)
>>    (dynamic-wind
>>        (lambda () #t)
>>        body-lambda
>>        ensuring-lambda))
>>
>> (define (with-sigaction signum handler flags lamb)
>>      (let ((old-sigaction (sigaction signum)))
>>        (if flags (sigaction signum handler flags) (sigaction signum handler))
>>        (ensure
>>         lamb
>>         (lambda ()
>>           (sigaction signum (car old-sigaction) (cdr old-sigaction))))))
>
> Signal handlers are invoked asynchronously as system asyncs, and system
> asyncs are run whenever `SCM_TICK' is encountered in the C code.
>
> There doesn't seem to be any Scheme procedure to force the execution of 
> system asyncs, but maybe you can try invoking LAMB above in 
> `call-with-unblocked-asyncs' and/or adding a `(sleep 0)' right before it 
> to force the execution of pending system asyncs.
>
> Let us know if it helps.

call-with-unblocked-asyncs complains:
     misc-error: asyncs already unblocked

With (sleep 0) is no different than without.

Thank you,
Grem

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)               I came, I saw, I thunked, I flunked.
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~

Re: signal handling different in 1.8.3 than 1.8.1?

[Ludovic Courtès]

Hello,

Gregory Marton <gremio@csail.mit.edu> writes:

>> The following message is a courtesy copy of an article
>> that has been posted to gmane.lisp.guile.bugs as well.
>
> Is bug-guile@gnu.org now out of date?   I may have to get a
> newsreader. Are they mirrored?

No, `bug-guile@gnu.org' is not outdated: it's just that I'm posting
through Gmane (http://gmane.org/), which is a mail/news bi-directional
gateway.  The above notice is issued (I think) by Gmane someone is
explicitly Cc'd to a newsgroup post.

> Nevertheless, it has consistently passed in 1.8.1 and consistently
> fails in 1.8.3 with no other changes.

Sure, but a quick glance at `NEWS' didn't reveal anything obviously
related to the problem at hand.

BTW, you might want to even switch to 1.8.5 while you're at it.

> call-with-unblocked-asyncs complains:
>     misc-error: asyncs already unblocked

OK, so it's not needed.

> With (sleep 0) is no different than without.

I just tried and it depends on where you place it.  For instance, a
`format' call (which also does `SCM_TICK' as a side effect) within the
second lambda passed to `ensure' in `with-sigaction' does the trick.

The key insight here is that signal delivery in Guile is asynchronous,
so you can't know for sure when it will happen.  It'd be nice to be able
to force system asyncs to run, though.

As to why there's such a reproducible difference between 1.8.1 and
1.8.3, maybe you could try using `git-bisect' to find out which change
set between tags `release_1-8-1' and `release_1-8-3' introduced the
change in behavior.  I think it's probably a side-effect of some
unrelated change but again, a valid side-effect.

Hope this helps,
Ludovic.

Re: signal handling different in 1.8.3 than 1.8.1?

[Gregory Marton]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3393 bytes --]

Aha!  So (sleep 0) did nothing, but interestingly (sleep 1) did -- but it 
didn't sleep 1!

So if I write this as
       (let ((sigcalled #f))
         (with-sigaction
  	SIGALRM (lambda (sig) (set! sigcalled #t)) #f
  	(lambda () (raise SIGALRM) (sleep 1)))
         (assert sigcalled "we set and handled an alarm"))
       (assert-equal orig (sigaction SIGALRM) "returned to the original state")
       (let ((outer "nop")
  	   (inner "nop"))
         (with-sigaction
  	   SIGALRM (lambda (sig) (set! outer "outer")) #f
  	   (lambda ()
  	     (with-sigaction
  		 SIGALRM (lambda (sig) (set! inner "inner")) #f
  		 (lambda ()
  		   (raise SIGALRM) (sleep 1)))
  	     (raise SIGALRM) (sleep 1)))
         (and (assert-equal "inner" inner "inner sig got handled")
  	    (assert-equal "outer" outer "outer sig got handled")))
       (assert-equal orig (sigaction SIGALRM) "returned to the original state")

then it passes.  I thought it should never reach those sleeps -- what's 
going on?  Also, it effectively doesn't reach the sleeps: the program 
passes the tests very quickly.

Grem

On Tue, 3 Jun 2008, Ludovic Courtès wrote:

> The following message is a courtesy copy of an article
> that has been posted to gmane.lisp.guile.bugs as well.
>
> Hello,
>
> Gregory Marton <gremio@csail.mit.edu> writes:
>
>>> The following message is a courtesy copy of an article
>>> that has been posted to gmane.lisp.guile.bugs as well.
>>
>> Is bug-guile@gnu.org now out of date?   I may have to get a
>> newsreader. Are they mirrored?
>
> No, `bug-guile@gnu.org' is not outdated: it's just that I'm posting
> through Gmane (http://gmane.org/), which is a mail/news bi-directional
> gateway.  The above notice is issued (I think) by Gmane someone is
> explicitly Cc'd to a newsgroup post.
>
>> Nevertheless, it has consistently passed in 1.8.1 and consistently
>> fails in 1.8.3 with no other changes.
>
> Sure, but a quick glance at `NEWS' didn't reveal anything obviously
> related to the problem at hand.
>
> BTW, you might want to even switch to 1.8.5 while you're at it.
>
>> call-with-unblocked-asyncs complains:
>>     misc-error: asyncs already unblocked
>
> OK, so it's not needed.
>
>> With (sleep 0) is no different than without.
>
> I just tried and it depends on where you place it.  For instance, a
> `format' call (which also does `SCM_TICK' as a side effect) within the
> second lambda passed to `ensure' in `with-sigaction' does the trick.
>
> The key insight here is that signal delivery in Guile is asynchronous,
> so you can't know for sure when it will happen.  It'd be nice to be able
> to force system asyncs to run, though.
> 
> As to why there's such a reproducible difference between 1.8.1 and
> 1.8.3, maybe you could try using `git-bisect' to find out which change
> set between tags `release_1-8-1' and `release_1-8-3' introduced the
> change in behavior.  I think it's probably a side-effect of some
> unrelated change but again, a valid side-effect.
>
> Hope this helps,
> Ludovic.
>

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)                  My religion . . . is kindness.
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~

Re: signal handling different in 1.8.3 than 1.8.1?

[Gregory Marton]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5263 bytes --]

Higher-level question:

As these are asynchronous, (alarm 10) could actually set off the alarm at 
any time after ten seconds.  Is it still possible to write with-timeout?

(define (with-timeout t thunk . handler)
      (let ((time-left (alarm 0))	;;time left on an outer alarm
  	  (start-time (current-time)))
        (alarm time-left)	;;continue the outer countdown
        (catch 'parent-timeout-error
  	(lambda ()
  	  (catch 'timeout-error
  	    (lambda ()
  	      (with-sigaction SIGALRM
  		(lambda (sig)
  		  (if (and (< time-left t) (not (equal? time-left 0)))
  		      (throw 'parent-timeout-error)
  		      (throw 'timeout-error)))
  		#f
  		(lambda ()
  		  (ensure
  		   (lambda ()
  		     (begin
  		      (if (or (< t time-left) (equal? time-left 0))
  			  (alarm t)) ;;time out in the shorter time, not the most recently set time
  		      (thunk)))
  		   (lambda ()
  		     (if (equal? time-left 0)
  			 (alarm 0)
  			 ;;reset the outer alarm if there was one, subtracting time taken by the thunk
  			 (let* ((time-taken (- (current-time) start-time))
  				(time-remaining (- time-left time-taken)))
  			   (alarm 0)
  			   (if (<= 0 time-remaining) ; guile 1.3 is broken and
  			       (alarm time-remaining) ; this can happen.
  			       (begin
  				 (raise SIGALRM)      ;better late than never?
  				 (sleep 1))))))))))
  	    (lambda (k . v)
  	      (if (null? handler)
  		  (throw k)
  		  ((car handler))))))
  	(lambda (k . v)
  	  (raise SIGALRM) (sleep 1)))))

To put it another way, I sure would like to have some guarantees about when 
some asynchronous things will happen.  Even with the (sleep 1)s, my 
with-timeout test cases fail.

Thanks,
Grem


> Aha!  So (sleep 0) did nothing, but interestingly (sleep 1) did -- but it 
> didn't sleep 1!
>
> So if I write this as
>      (let ((sigcalled #f))
>        (with-sigaction
> 	SIGALRM (lambda (sig) (set! sigcalled #t)) #f
> 	(lambda () (raise SIGALRM) (sleep 1)))
>        (assert sigcalled "we set and handled an alarm"))
>      (assert-equal orig (sigaction SIGALRM) "returned to the original 
> state")
>      (let ((outer "nop")
> 	   (inner "nop"))
>        (with-sigaction
> 	   SIGALRM (lambda (sig) (set! outer "outer")) #f
> 	   (lambda ()
> 	     (with-sigaction
> 		 SIGALRM (lambda (sig) (set! inner "inner")) #f
> 		 (lambda ()
> 		   (raise SIGALRM) (sleep 1)))
> 	     (raise SIGALRM) (sleep 1)))
>        (and (assert-equal "inner" inner "inner sig got handled")
> 	    (assert-equal "outer" outer "outer sig got handled")))
>      (assert-equal orig (sigaction SIGALRM) "returned to the original 
> state")
>
> then it passes.  I thought it should never reach those sleeps -- what's going 
> on?  Also, it effectively doesn't reach the sleeps: the program passes the 
> tests very quickly.
>
> Grem
>
> On Tue, 3 Jun 2008, Ludovic Courtès wrote:
>
>> The following message is a courtesy copy of an article
>> that has been posted to gmane.lisp.guile.bugs as well.
>> 
>> Hello,
>> 
>> Gregory Marton <gremio@csail.mit.edu> writes:
>> 
>>>> The following message is a courtesy copy of an article
>>>> that has been posted to gmane.lisp.guile.bugs as well.
>>> 
>>> Is bug-guile@gnu.org now out of date?   I may have to get a
>>> newsreader. Are they mirrored?
>> 
>> No, `bug-guile@gnu.org' is not outdated: it's just that I'm posting
>> through Gmane (http://gmane.org/), which is a mail/news bi-directional
>> gateway.  The above notice is issued (I think) by Gmane someone is
>> explicitly Cc'd to a newsgroup post.
>> 
>>> Nevertheless, it has consistently passed in 1.8.1 and consistently
>>> fails in 1.8.3 with no other changes.
>> 
>> Sure, but a quick glance at `NEWS' didn't reveal anything obviously
>> related to the problem at hand.
>> 
>> BTW, you might want to even switch to 1.8.5 while you're at it.
>> 
>>> call-with-unblocked-asyncs complains:
>>>     misc-error: asyncs already unblocked
>> 
>> OK, so it's not needed.
>> 
>>> With (sleep 0) is no different than without.
>> 
>> I just tried and it depends on where you place it.  For instance, a
>> `format' call (which also does `SCM_TICK' as a side effect) within the
>> second lambda passed to `ensure' in `with-sigaction' does the trick.
>> 
>> The key insight here is that signal delivery in Guile is asynchronous,
>> so you can't know for sure when it will happen.  It'd be nice to be able
>> to force system asyncs to run, though.
>> 
>> As to why there's such a reproducible difference between 1.8.1 and
>> 1.8.3, maybe you could try using `git-bisect' to find out which change
>> set between tags `release_1-8-1' and `release_1-8-3' introduced the
>> change in behavior.  I think it's probably a side-effect of some
>> unrelated change but again, a valid side-effect.
>> 
>> Hope this helps,
>> Ludovic.
>> 
>
>

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)       Am I sure?  Sure is just what I'm not anything but!
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~

Re: signal handling different in 1.8.3 than 1.8.1?

[Ludovic Courtès]

Hi,

Gregory Marton <gremio@csail.mit.edu> writes:

> As these are asynchronous, (alarm 10) could actually set off the alarm
> at any time after ten seconds.  Is it still possible to write
> with-timeout?

[...]

> To put it another way, I sure would like to have some guarantees about
> when some asynchronous things will happen.  Even with the (sleep 1)s,
> my with-timeout test cases fail.

That's a good question.  Technically, all blocking calls like `sleep'
and `select' (anything that calls `scm_std_select ()') run the system
asyncs.  The evaluator also runs them periodically, typically anytime a
procedure is invoked (look for `SCM_TICK' in `CEVAL ()').  So, normally,
system asyncs should be run "as soon as possible".

The `(statprof)' module in Guile-Library, for instance, uses a SIGPROF
handler to do statistical profiling.  Now, it's unclear what latency
there is between signal delivery and handler invocation, and it's
unclear what influences it...

Thoughts?

Thanks,
Ludovic.

Re: signal handling different in 1.8.3 than 1.8.1?

[Gregory Marton]

Hi Ludovic,

Thanks for the handholding Re: git-bisect.

>> there are frustrating failures like there not being a ./configure
>> script in many older versions even though the INSTALL document says
>> there should be, and ./autogen.sh complaining that
>> aclocal:configure.in:704: warning: macro `AM_GNU_GETTEXT' not found in library
>> and so on.
>
> There aren't any generated files in the repository.  Thus, you need to
> run "autoreconf -i --force" or "./autogen.sh" to produce `configure' et
> al.  The above warning is harmless.

I'm still having no luck building even the first intermediate stage, 
however.

$ ./autogen.sh
    ERROR: could not find workbook dir
    re-run like so: ./autogen.sh WORKBOOK

$ autoreconf -i --force
    aclocal:configure.in:694: warning: macro `AM_GNU_GETTEXT' not found in library
    aclocal:configure.in:694: warning: macro `AM_GNU_GETTEXT' not found in library
    configure.in:717: error: possibly undefined macro: AM_GNU_GETTEXT
        If this token and others are legitimate, please use m4_pattern_allow.
        See the Autoconf documentation.
    autoreconf: /usr/bin/autoconf failed with exit status: 1
$ ./configure
configure: error: cannot find install-sh or install.sh in . "."/.

I don't know how to interpret these.  Incidentally, aptitude says I have 
gettext.
i   gettext                         - GNU Internationalization utilities
i   gettext-base                    - GNU Internationalization utilities for

Thanks,
Grem

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)                 It's been Monday all week today.
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~

Re: signal handling different in 1.8.3 than 1.8.1?

[Ludovic Courtès]

Hi Gregory,

Gregory Marton <gremio@csail.mit.edu> writes:

> I'm still having no luck building even the first intermediate stage,
> however.
>
> $ ./autogen.sh
>    ERROR: could not find workbook dir
>    re-run like so: ./autogen.sh WORKBOOK

What checkout are you using?  This looks like an ancient thing.  Can you
make sure to clone the current Git repository?

  $ git-clone git://git.sv.gnu.org/guile.git
  $ cd guile
  $ git-branch --track branch_release-1-8 origin/branch_release-1-8
  $ git-checkout branch_release-1-8

> i   gettext                         - GNU Internationalization utilities
> i   gettext-base                    - GNU Internationalization utilities for

Maybe this should be `gettext-dev'?

Thanks,
Ludovic.

Re: signal handling different in 1.8.3 than 1.8.1?

[Gregory Marton]

Hi Ludovic,

The first bisect is version 3591d9f5a94bd962217761dd038f853c23964132
Thank you for the additional git handholding.

Aptitude does not recognize a package gettext-dev, but perhaps the problem 
is just that Debian's stable gettext is too old (as it was with git)?  The 
version I have appears to be 0.16.1.  I am not sure how to use apt to 
search for a string like AM_GNU_GETTEXT in all available packages.

Thanks again,
Grem

> Hi Gregory,
>
> Gregory Marton <gremio@csail.mit.edu> writes:
>
>> I'm still having no luck building even the first intermediate stage,
>> however.
>>
>> $ ./autogen.sh
>>    ERROR: could not find workbook dir
>>    re-run like so: ./autogen.sh WORKBOOK
>
> What checkout are you using?  This looks like an ancient thing.  Can you
> make sure to clone the current Git repository?
>
>  $ git-clone git://git.sv.gnu.org/guile.git
>  $ cd guile
>  $ git-branch --track branch_release-1-8 origin/branch_release-1-8
>  $ git-checkout branch_release-1-8
>
>> i   gettext                         - GNU Internationalization utilities
>> i   gettext-base                    - GNU Internationalization utilities for
>
> Maybe this should be `gettext-dev'?
>
> Thanks,
> Ludovic.
>
>
>
>

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)        A free society is where it's safe to be unpopular.
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~

Re: signal handling different in 1.8.3 than 1.8.1?

[Gregory Marton]

Indeed, installing gettext 1.7 from source helped, though autoreconf still 
complains:

autoreconf: configure.in: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION

I'll start dealing with the next message
    Makefile.am:25: require Automake 1.10, but have 1.9

A similar message for gettext would have been less confusing, and very 
welcome.

Thanks,
Grem

> Hi Ludovic,
>
> The first bisect is version 3591d9f5a94bd962217761dd038f853c23964132
> Thank you for the additional git handholding.
>
> Aptitude does not recognize a package gettext-dev, but perhaps the problem is 
> just that Debian's stable gettext is too old (as it was with git)?  The 
> version I have appears to be 0.16.1.  I am not sure how to use apt to search 
> for a string like AM_GNU_GETTEXT in all available packages.
>
> Thanks again,
> Grem
>
>> Hi Gregory,
>> 
>> Gregory Marton <gremio@csail.mit.edu> writes:
>> 
>>> I'm still having no luck building even the first intermediate stage,
>>> however.
>>> 
>>> $ ./autogen.sh
>>>    ERROR: could not find workbook dir
>>>    re-run like so: ./autogen.sh WORKBOOK
>> 
>> What checkout are you using?  This looks like an ancient thing.  Can you
>> make sure to clone the current Git repository?
>>
>>  $ git-clone git://git.sv.gnu.org/guile.git
>>  $ cd guile
>>  $ git-branch --track branch_release-1-8 origin/branch_release-1-8
>>  $ git-checkout branch_release-1-8
>> 
>>> i   gettext                         - GNU Internationalization utilities
>>> i   gettext-base                    - GNU Internationalization utilities 
>>> for
>> 
>> Maybe this should be `gettext-dev'?
>> 
>> Thanks,
>> Ludovic.
>> 
>> 
>> 
>> 
>
>

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)                         Codito Ergo Sum
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~

Re: signal handling different in 1.8.3 than 1.8.1?

[Gregory Marton]

Now with automake 1.10, autoreconf -i --force complains,

   configure.in:717: required file `./config.rpath' not found

How may I provide that?

Thanks,
Grem


> Indeed, installing gettext 1.7 from source helped, though autoreconf still 
> complains:
>
> autoreconf: configure.in: AM_GNU_GETTEXT is used, but not 
> AM_GNU_GETTEXT_VERSION
>
> I'll start dealing with the next message
>   Makefile.am:25: require Automake 1.10, but have 1.9
>
> A similar message for gettext would have been less confusing, and very 
> welcome.
>
> Thanks,
> Grem
>
>> Hi Ludovic,
>> 
>> The first bisect is version 3591d9f5a94bd962217761dd038f853c23964132
>> Thank you for the additional git handholding.
>> 
>> Aptitude does not recognize a package gettext-dev, but perhaps the problem 
>> is just that Debian's stable gettext is too old (as it was with git)?  The 
>> version I have appears to be 0.16.1.  I am not sure how to use apt to 
>> search for a string like AM_GNU_GETTEXT in all available packages.
>> 
>> Thanks again,
>> Grem
>> 
>>> Hi Gregory,
>>> 
>>> Gregory Marton <gremio@csail.mit.edu> writes:
>>> 
>>>> I'm still having no luck building even the first intermediate stage,
>>>> however.
>>>> 
>>>> $ ./autogen.sh
>>>>    ERROR: could not find workbook dir
>>>>    re-run like so: ./autogen.sh WORKBOOK
>>> 
>>> What checkout are you using?  This looks like an ancient thing.  Can you
>>> make sure to clone the current Git repository?
>>>
>>>  $ git-clone git://git.sv.gnu.org/guile.git
>>>  $ cd guile
>>>  $ git-branch --track branch_release-1-8 origin/branch_release-1-8
>>>  $ git-checkout branch_release-1-8
>>> 
>>>> i   gettext                         - GNU Internationalization utilities
>>>> i   gettext-base                    - GNU Internationalization utilities 
>>>> for
>>> 
>>> Maybe this should be `gettext-dev'?
>>> 
>>> Thanks,
>>> Ludovic.
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>
>

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)              The perfect is the enemy of the good.
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~

Re: signal handling different in 1.8.3 than 1.8.1?

[Ludovic Courtès]

Hi,

Gregory Marton <gremio@csail.mit.edu> writes:

> Now with automake 1.10, autoreconf -i --force complains,
>
>   configure.in:717: required file `./config.rpath' not found
>
> How may I provide that?

This should be installed by "autoreconf -fi" or "./autogen.sh", or
perhaps by "gettextize -f".

Hope this helps,
Ludovic.

Re: signal handling different in 1.8.3 than 1.8.1?

[Gregory Marton]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1448 bytes --]

Hi,

It turns out I can't find a repository revision where it works.  All of the 
major tagged releases fail, including 1.8.1, which makes me suspicious, 
because my Debian-installed guile 1.8.1 continues to work (see below).  Is 
there a place to look for Debian's possible modifications to guile? Might 
something else be going on?

I've attached a small test suite that should demonstrate the problem.  Can 
anyone else reproduce it?  Can anyone else see it pass on 1.8.1 or any 
other version?

Thanks,
Grem

$ /usr/bin/guile ../test-timeout.scm
1.8.1
good!
$ libguile/guile ../test-timeout.scm
1.8.1
fell asleepExpected: specified handler
Observed: #<unspecified>
should time out with specified handler
$ git log | head -1  # tag release_1-8-1
commit 2e726f11258f3d77557310fd50c02774fdcf014f


> Hi,
>
> Gregory Marton <gremio@csail.mit.edu> writes:
>
>> Now with automake 1.10, autoreconf -i --force complains,
>>
>>   configure.in:717: required file `./config.rpath' not found
>>
>> How may I provide that?
>
> This should be installed by "autoreconf -fi" or "./autogen.sh", or
> perhaps by "gettextize -f".
>
> Hope this helps,
> Ludovic.
>
>
>
>

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)                 When two hearts race, both win.
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~

[-- Attachment #2: Type: TEXT/PLAIN, Size: 4305 bytes --]


(define (ensure body-lambda ensuring-lambda)
  (dynamic-wind
      (lambda () #t)
      body-lambda
      ensuring-lambda))

(define (with-sigaction signum handler flags lamb)
    (let ((old-sigaction (sigaction signum)))
      (if flags (sigaction signum handler flags) (sigaction signum handler))
      (ensure 
       lamb
       (lambda ()
	 (sigaction signum (car old-sigaction) (cdr old-sigaction))))))

(define (with-timeout t thunk . handler)  
    (let ((time-left (alarm 0))	;;time left on an outer alarm
	  (start-time (current-time)))
      (alarm time-left)	;;continue the outer countdown
      (catch 'parent-timeout-error
	(lambda ()
	  (catch 'timeout-error
	    (lambda ()
	      (with-sigaction SIGALRM
		(lambda (sig)
		  (if (and (< time-left t) (not (equal? time-left 0)))
		      (throw 'parent-timeout-error) 
		      (throw 'timeout-error)))     
		#f    
		(lambda ()
		  (ensure 
		   (lambda ()  
		     (begin
		      (if (or (< t time-left) (equal? time-left 0))   
			  (alarm t)) ;;time out in the shorter time, not the most recently set time
		      (thunk)))
		   (lambda ()
		     (if (equal? time-left 0) 
			 (alarm 0)
			 ;;reset the outer alarm if there was one, subtracting time taken by the thunk
			 (let* ((time-taken (- (current-time) start-time))
				(time-remaining (- time-left time-taken))) 
			   (alarm 0) 
			   (if (<= 0 time-remaining) ; guile 1.3 is broken and
			       (alarm time-remaining) ; this can happen.
			       (raise SIGALRM))))))))) ;better late than never?
	    (lambda (k . v)
	      (if (null? handler)
		  (throw k)
		  ((car handler))))))
	(lambda (k . v)
	  (raise SIGALRM)))))

(define (assert-equals expected observed message)
  (if (equal? expected observed) 
      #t
      (begin
	(map display (list "Expected: " expected "\nObserved: " observed
			   "\n" message "\n")) 
	#f)))

(display (version)) (newline)
(if (and 
     (assert-equals 7 (with-timeout 2 (lambda () (+ 2 5))) 
		    "should not time out")
     
     (assert-equals 
      'caught 
      (catch 'timeout-error 
	     (lambda () (with-timeout 2 (lambda () 
					  (while #t "infinite monkeys"))))
	     (lambda (k . v) 'caught))
      "should time out with default handler")     
     
     (assert-equals 
      "specified handler"
      (with-timeout 2
		    (lambda () (begin (sleep 4) (display "fell asleep")))
		    (lambda () "specified handler"))  
      "should time out with specified handler")
     
     (assert-equals
      9
      (with-timeout 2
		    (lambda ()
		      (let ((foo (+ 2 3)))
			(with-timeout 2 (lambda () (+ foo 4))))))
      "nested timeouts that should not time out")
     
     (assert-equals
      "inner timeout"
      (with-timeout 5
		    (lambda ()
		      (let ((foo (+ 2 3)))
			(with-timeout 2
				      (lambda () (sleep 10))
				      (lambda () "inner timeout"))))
		    (lambda () "outer timeout"))
      "nested timeouts where the inner one should time out")
     
     (assert-equals
      "outer timeout"
      (with-timeout 2
		    (lambda ()
		      (let ((foo (+ 2 3)))
			(with-timeout 
			 5
			 (lambda ()
			   (begin
			     (sleep 10)
			     (display "oh no, you fell asleep!")))
			 (lambda () "inner timeout"))))
		    (lambda () "outer timeout"))
      "outer time has expired, and outer handler is used")
     
     (assert-equals
      "outer timeout" 
      (with-timeout 2
		    (lambda ()
		      (let ((foo (+ 2 3)))
			(with-timeout 5 
				      (lambda () (+ 8 7)) 
				      (lambda () "inner timeout"))
			(sleep 10)
			"oh no, you fell asleep!"))
		    (lambda () "outer timeout"))   
      (string-append "nested timeouts where the inner one should finish "
		     "but the outer one should still time out"))
     
     (assert-equals
      "outer timeout" 
      (with-timeout 2
		    (lambda ()
		      (let ((foo (+ 2 3)))
			(with-timeout 2
				      (lambda ()
					(+ 8 7))
				      (lambda ()
					"inner timeout"))
			(sleep 10)
			"oh no, you fell asleep!"))
		    (lambda ()
		      "outer timeout")) 
      "when the times are the same, the outer handler is used")
     )
    (display "good!\n")
    (primitive-exit 1))
    

Re: signal handling different in 1.8.3 than 1.8.1?

[Ludovic Courtès]

Hi,

Gregory Marton <gremio@csail.mit.edu> writes:

> It turns out I can't find a repository revision where it works.  All
> of the major tagged releases fail, including 1.8.1, which makes me
> suspicious, because my Debian-installed guile 1.8.1 continues to work
> (see below).  Is there a place to look for Debian's possible
> modifications to guile? Might something else be going on?

IIRC, 1.8.1 was compiled with `--without-threads', so you might want to
try it.  Debian-specific modifications are available in the Debian
archive, i.e.,
ftp://ftp.debian.org/debian/pool/main/g/guile-1.8/guile-1.8_1.8.1+1-4.diff.gz .

> I've attached a small test suite that should demonstrate the problem.
> Can anyone else reproduce it?  Can anyone else see it pass on 1.8.1 or
> any other version?

With `master':

  $ guile ~/tmp/test-timeout.scm 
  1.9.0
  fell asleepoh no, you fell asleep!Expected: outer timeout
  Observed: #<unspecified>
  outer time has expired, and outer handler is used

> $ libguile/guile ../test-timeout.scm

You should instead use the `pre-inst-guile' script.

Thanks,
Ludovic.

Re: signal handling different in 1.8.3 than 1.8.1?

[Gregory Marton]

While trying to compile the latest on the 1.8 branch,

gen-scmconfig.c: In function 'main':
gen-scmconfig.c:388: error: stray '@' in program
gen-scmconfig.c:388: error: stray '@' in program
gen-scmconfig.c:388: error: 
'SCM_I_GSC_NEED_BRACES_ON_PTHREAD_MUTEX_INITIALIZER' undeclared (first use 
in this function)
gen-scmconfig.c:388: error: (Each undeclared identifier is reported only 
once
gen-scmconfig.c:388: error: for each function it appears in.)
gen-scmconfig.c:394: error: stray '@' in program
gen-scmconfig.c:394: error: stray '@' in program
gen-scmconfig.c:394: error: 'SCM_I_GSC_HAVE_STRUCT_DIRENT64' undeclared 
(first use in this function)

during make, with or without having invoked config with --without-threads

Help?
Grem

> Hi,
>
> Gregory Marton <gremio@csail.mit.edu> writes:
>
>> It turns out I can't find a repository revision where it works.  All
>> of the major tagged releases fail, including 1.8.1, which makes me
>> suspicious, because my Debian-installed guile 1.8.1 continues to work
>> (see below).  Is there a place to look for Debian's possible
>> modifications to guile? Might something else be going on?
>
> IIRC, 1.8.1 was compiled with `--without-threads', so you might want to
> try it.  Debian-specific modifications are available in the Debian
> archive, i.e.,
> ftp://ftp.debian.org/debian/pool/main/g/guile-1.8/guile-1.8_1.8.1+1-4.diff.gz .
>
>> I've attached a small test suite that should demonstrate the problem.
>> Can anyone else reproduce it?  Can anyone else see it pass on 1.8.1 or
>> any other version?
>
> With `master':
>
>  $ guile ~/tmp/test-timeout.scm
>  1.9.0
>  fell asleepoh no, you fell asleep!Expected: outer timeout
>  Observed: #<unspecified>
>  outer time has expired, and outer handler is used
>
>> $ libguile/guile ../test-timeout.scm
>
> You should instead use the `pre-inst-guile' script.
>
> Thanks,
> Ludovic.
>
>
>
>

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)            Bushydo -- the way of the shrub.  Bonsai!
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~

Re: signal handling different in 1.8.3 than 1.8.1?

[Ludovic Courtès]

Hi Gregory,

Gregory Marton <gremio@csail.mit.edu> writes:

> While trying to compile the latest on the 1.8 branch,
>
> gen-scmconfig.c: In function 'main':
> gen-scmconfig.c:388: error: stray '@' in program

This indicates that your `scmconfig.h' is broken.

Normally, `scmconfig.h' is produced from `scmconfig.h.in' by
`config.status', i.e., at the end of the `configure' run.  All `@'
variables found in the `.in' file should be substituted by their value,
which is not the case here.

You may want to run "make distclean && autoheader && autoreconf -vfi"
and then rebuild the whole thing:

  $ ./configure -C --enable-maintainer-mode && make all check

Hope this helps,
Ludovic.

Re: signal handling different in 1.8.3 than 1.8.1?

[Gregory Marton]

Excellent.

Having done these steps, it did indeed make check, and with the 
--without-threads flag, it even passed the timeout tests!

I'm happy with this for now.  Is non-threading ever likely to be 
unsupported?

Thanks,
Grem


> Hi Gregory,
>
> Gregory Marton <gremio@csail.mit.edu> writes:
>
>> While trying to compile the latest on the 1.8 branch,
>>
>> gen-scmconfig.c: In function 'main':
>> gen-scmconfig.c:388: error: stray '@' in program
>
> This indicates that your `scmconfig.h' is broken.
>
> Normally, `scmconfig.h' is produced from `scmconfig.h.in' by
> `config.status', i.e., at the end of the `configure' run.  All `@'
> variables found in the `.in' file should be substituted by their value,
> which is not the case here.
>
> You may want to run "make distclean && autoheader && autoreconf -vfi"
> and then rebuild the whole thing:
>
>  $ ./configure -C --enable-maintainer-mode && make all check
>
> Hope this helps,
> Ludovic.
>
>
>
>

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)               Things are going from bad to verse!
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~

Re: signal handling different in 1.8.3 than 1.8.1?

[Ludovic Courtès]

Hi,

Gregory Marton <gremio@csail.mit.edu> writes:

> Having done these steps, it did indeed make check, and with the
> --without-threads flag, it even passed the timeout tests!

You mean that the problem that triggered this thread vanished?

> I'm happy with this for now.  Is non-threading ever likely to be
> unsupported?

There's no plan to remove mono-threading AFAIK.

Thanks,
Ludovic.

Re: signal handling different in 1.8.3 than 1.8.1?

[Gregory Marton]

> Gregory Marton <gremio@csail.mit.edu> writes:
>
>> Having done these steps, it did indeed make check, and with the
>> --without-threads flag, it even passed the timeout tests!
>
> You mean that the problem that triggered this thread vanished?

Yes.  The with-timeout test script I sent a few emails ago passes if the 
latest 1.8 branch guile is compiled without threads.  I guess either signal 
handling or sleep is somehow different when threading is enabled.

They're taking a while to run, but so far all my other tests are also 
passing in mono-threaded guile 1.8.5
   commit 9143131b2766d1e29e05d61b5021395b4c93a6bc Neil Jerram, July 11

>> I'm happy with this for now.  Is non-threading ever likely to be
>> unsupported?
>
> There's no plan to remove mono-threading AFAIK.

Thank you.

Grem

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)              bigamy: where two rites make a wrong.
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~

Re: signal handling different in 1.8.3 than 1.8.1?

[Neil Jerram]

2008/7/17 Gregory Marton <gremio@csail.mit.edu>:
>
>
> They're taking a while to run, but so far all my other tests are also
> passing in mono-threaded guile 1.8.5
>  commit 9143131b2766d1e29e05d61b5021395b4c93a6bc Neil Jerram, July 11

Just to be clear: do you mean that they are passing _after_ this
commit, but were failing _before_?  That's nice to know if so!  What
are your OS and compiler version?

Thanks,
        Neil

Re: signal handling different in 1.8.3 than 1.8.1?

[Gregory Marton]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1850 bytes --]

>> They're taking a while to run, but so far all my other tests are also
>> passing in mono-threaded guile 1.8.5
>>  commit 9143131b2766d1e29e05d61b5021395b4c93a6bc Neil Jerram, July 11
>
> Just to be clear: do you mean that they are passing _after_ this
> commit, but were failing _before_?  That's nice to know if so!  What
> are your OS and compiler version?

Hi Neil,

I mean that for every commit between this one and 1.8.0 that I've tested, 
the default compile has failed the tests, and that for both 1.8.1 and this 
commit (I have tested none between) compiling --without-threads makes my 
tests pass.

I would surmise that this is an extremely longstanding issue that was 
introduced some time before 1.8.1, and that I only noticed it now because I 
was trying to use the default build.  I do not assert that it has anything 
at all to do with this particular commit -- I just wanted to let people 
know where my newest endpoint was.  Sorry to be unclear.

I'm running on a modified debian 32-bit architecture. I can't say exactly 
how it's modified because my institution, not I, did the modifications.

However, I have attached again the scheme code to test this condition.  I 
hope it will be helpful in tracking down the issue.  For my own sake, I'm 
happy to use mono-threaded guile.

If you do find the threading issue, I would love it if some version of 
with-timeout were to make it into the guile core.  It's useful.  I 
apologise for letting the copyright assignment issue stall somewhere.  I'll 
look into it again.

Thanks,
Grem

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)         Premature optimization is the root of all evil.
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~

[-- Attachment #2: Type: TEXT/PLAIN, Size: 4305 bytes --]


(define (ensure body-lambda ensuring-lambda)
  (dynamic-wind
      (lambda () #t)
      body-lambda
      ensuring-lambda))

(define (with-sigaction signum handler flags lamb)
    (let ((old-sigaction (sigaction signum)))
      (if flags (sigaction signum handler flags) (sigaction signum handler))
      (ensure 
       lamb
       (lambda ()
	 (sigaction signum (car old-sigaction) (cdr old-sigaction))))))

(define (with-timeout t thunk . handler)  
    (let ((time-left (alarm 0))	;;time left on an outer alarm
	  (start-time (current-time)))
      (alarm time-left)	;;continue the outer countdown
      (catch 'parent-timeout-error
	(lambda ()
	  (catch 'timeout-error
	    (lambda ()
	      (with-sigaction SIGALRM
		(lambda (sig)
		  (if (and (< time-left t) (not (equal? time-left 0)))
		      (throw 'parent-timeout-error) 
		      (throw 'timeout-error)))     
		#f    
		(lambda ()
		  (ensure 
		   (lambda ()  
		     (begin
		      (if (or (< t time-left) (equal? time-left 0))   
			  (alarm t)) ;;time out in the shorter time, not the most recently set time
		      (thunk)))
		   (lambda ()
		     (if (equal? time-left 0) 
			 (alarm 0)
			 ;;reset the outer alarm if there was one, subtracting time taken by the thunk
			 (let* ((time-taken (- (current-time) start-time))
				(time-remaining (- time-left time-taken))) 
			   (alarm 0) 
			   (if (<= 0 time-remaining) ; guile 1.3 is broken and
			       (alarm time-remaining) ; this can happen.
			       (raise SIGALRM))))))))) ;better late than never?
	    (lambda (k . v)
	      (if (null? handler)
		  (throw k)
		  ((car handler))))))
	(lambda (k . v)
	  (raise SIGALRM)))))

(define (assert-equals expected observed message)
  (if (equal? expected observed) 
      #t
      (begin
	(map display (list "Expected: " expected "\nObserved: " observed
			   "\n" message "\n")) 
	#f)))

(display (version)) (newline)
(if (and 
     (assert-equals 7 (with-timeout 2 (lambda () (+ 2 5))) 
		    "should not time out")
     
     (assert-equals 
      'caught 
      (catch 'timeout-error 
	     (lambda () (with-timeout 2 (lambda () 
					  (while #t "infinite monkeys"))))
	     (lambda (k . v) 'caught))
      "should time out with default handler")     
     
     (assert-equals 
      "specified handler"
      (with-timeout 2
		    (lambda () (begin (sleep 4) (display "fell asleep")))
		    (lambda () "specified handler"))  
      "should time out with specified handler")
     
     (assert-equals
      9
      (with-timeout 2
		    (lambda ()
		      (let ((foo (+ 2 3)))
			(with-timeout 2 (lambda () (+ foo 4))))))
      "nested timeouts that should not time out")
     
     (assert-equals
      "inner timeout"
      (with-timeout 5
		    (lambda ()
		      (let ((foo (+ 2 3)))
			(with-timeout 2
				      (lambda () (sleep 10))
				      (lambda () "inner timeout"))))
		    (lambda () "outer timeout"))
      "nested timeouts where the inner one should time out")
     
     (assert-equals
      "outer timeout"
      (with-timeout 2
		    (lambda ()
		      (let ((foo (+ 2 3)))
			(with-timeout 
			 5
			 (lambda ()
			   (begin
			     (sleep 10)
			     (display "oh no, you fell asleep!")))
			 (lambda () "inner timeout"))))
		    (lambda () "outer timeout"))
      "outer time has expired, and outer handler is used")
     
     (assert-equals
      "outer timeout" 
      (with-timeout 2
		    (lambda ()
		      (let ((foo (+ 2 3)))
			(with-timeout 5 
				      (lambda () (+ 8 7)) 
				      (lambda () "inner timeout"))
			(sleep 10)
			"oh no, you fell asleep!"))
		    (lambda () "outer timeout"))   
      (string-append "nested timeouts where the inner one should finish "
		     "but the outer one should still time out"))
     
     (assert-equals
      "outer timeout" 
      (with-timeout 2
		    (lambda ()
		      (let ((foo (+ 2 3)))
			(with-timeout 2
				      (lambda ()
					(+ 8 7))
				      (lambda ()
					"inner timeout"))
			(sleep 10)
			"oh no, you fell asleep!"))
		    (lambda ()
		      "outer timeout")) 
      "when the times are the same, the outer handler is used")
     )
    (display "good!\n")
    (primitive-exit 1))
    

Re: signal handling different in 1.8.3 than 1.8.1?

[Ludovic Courtès]

Hello,

Gregory Marton <gremio@csail.mit.edu> writes:

> I would surmise that this is an extremely longstanding issue that was
> introduced some time before 1.8.1, and that I only noticed it now
> because I was trying to use the default build.

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.

Thanks,
Ludovic.

[0] http://thread.gmane.org/gmane.lisp.guile.bugs/3889

Re: signal handling different in 1.8.3 than 1.8.1?

[Gregory Marton]

> Hello,
>
> Gregory Marton <gremio@csail.mit.edu> writes:
>
>> I would surmise that this is an extremely longstanding issue that was
>> introduced some time before 1.8.1, and that I only noticed it now
>> because I was trying to use the default build.
>
> 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.

Grem

-- 
------ __@   Gregory A. Marton                http://csail.mit.edu/~gremio/
--- _`\<,_                                                                .
-- (*)/ (*)                      No solicitors over 18.
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~

Re: signal handling different in 1.8.3 than 1.8.1?

[Ludovic Courtès]

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

Re: with-timeout and asynchronous alarm (was: signal handling different in 1.8.3 than 1.8.1?)

[Gregory Marton]

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~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~