bug#43757: cuirass: Fail to fetch "guix" input.

bug#43757: cuirass: Fail to fetch "guix" input.

[Mathieu Othacehe]

Hello,

Running local tests, I have the following error:

--8<---------------cut here---------------start------------->8---
2020-10-02T11:54:09 fatal: uncaught exception 'misc-error' in 'build' fiber!
2020-10-02T11:54:09 exception arguments: (#f "Attempt to suspend fiber within continuation barrier" () #f)
In ice-9/boot-9.scm:
  1731:15 13 (with-exception-handler #<procedure 7f4eb362df60 at ic?> ?)
  1736:10 12 (with-exception-handler _ _ #:unwind? _ # _)
    152:2 11 (with-fluid* _ _ _)
    718:2 10 (call-with-prompt ("break") #<procedure 7f4eb76adb60 a?> ?)
    718:2  9 (call-with-prompt ("continue") #<procedure 7f4eb76ad14?> ?)
In ice-9/eval.scm:
    619:8  8 (_ #(#(#<directory (guile-user) 7f4eb72d7f00> #<var?> ?)))
In srfi/srfi-1.scm:
    634:9  7 (for-each #<procedure 7f4eb3750660 at cuirass/base.scm?> ?)
In ice-9/boot-9.scm:
  1731:15  6 (with-exception-handler #<procedure 7f4eb3673ba0 at ic?> ?)
  1669:16  5 (raise-exception _ #:continuable? _)
  1764:13  4 (_ #<&compound-exception components: (#<&error> #<&orig?>)
In cuirass/utils.scm:
    240:8  3 (_ _ . _)
In ice-9/boot-9.scm:
  1731:15  2 (with-exception-handler #<procedure 7f4eb7616480 at ic?> ?)
In cuirass/utils.scm:
   241:22  1 (_)
In unknown file:
           0 (make-stack #t)
ERROR: In procedure make-stack:
Attempt to suspend fiber within continuation barrier
--8<---------------cut here---------------end--------------->8---

the specification is:

--8<---------------cut here---------------start------------->8---
(define manifest
  '((#:name . "my-manifest")
    (#:load-path-inputs . ("guix"))
    (#:package-path-inputs . ())
    (#:proc-input . "guix")
    (#:proc-file . "build-aux/cuirass/gnu-system.scm")
    (#:proc . cuirass-jobs)
    (#:proc-args (subset . "all"))
    (#:inputs . (((#:name . "guix")
                  (#:url . "git://git.savannah.gnu.org/guix.git")
                  (#:load-path . ".")
                  (#:branch . "master")
                  (#:no-compile? . #t))
                 ((#:name . "guix2")
                  (#:url . "git://git.savannah.gnu.org/guix.git")
                  (#:load-path . ".")
                  (#:branch . "master")
                  (#:no-compile? . #t))))
    (#:build-outputs . ())))
(list manifest)
--8<---------------cut here---------------end--------------->8---

It looks like adding a second input, creates an exception during inputs
fetching.

Thanks,

Mathieu

-- 
https://othacehe.org

bug#43757: cuirass: Fail to fetch "guix" input.

[Mathieu Othacehe]

Hello,

> ERROR: In procedure make-stack:
> Attempt to suspend fiber within continuation barrier

Turns out "par-map" call does not seem suspendable, even though I'm not
sure why. Maybe Ludo can help here :) ?

This is fixed with: 761443bca6178b4ac299a8bd368d1cac4abda5f8.

Thanks,

Mathieu

bug#43757: cuirass: Fail to fetch "guix" input.

[Ludovic Courtès]

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

>> ERROR: In procedure make-stack:
>> Attempt to suspend fiber within continuation barrier
>
> Turns out "par-map" call does not seem suspendable, even though I'm not
> sure why. Maybe Ludo can help here :) ?

‘par-map’ is implemented in terms of futures, and futures use their own
thread pool.  What’s likely to block is ‘touch’: it essentially waits on
a condition variable, which Fibers cannot interrupt.

I’d say that mixing fibers and ‘par-map’ is a bad idea.  :-)

If we need such a thing, I think we should implement it on top of
Fibers.  Implementing futures on top of fibers + channels should be
easier than what (ice-9 futures) does.

> This is fixed with: 761443bca6178b4ac299a8bd368d1cac4abda5f8.

Why not just replace ‘par-map’ with ‘map’?  That sounds easier and I
suspect it doesn’t change much performance-wise.

(There’s a 2nd use of ‘par-map’ in that file.)

Thanks,
Ludo’.

bug#43757: cuirass: Fail to fetch "guix" input.

[Mathieu Othacehe]

Hey Ludo,

> ‘par-map’ is implemented in terms of futures, and futures use their own
> thread pool.  What’s likely to block is ‘touch’: it essentially waits on
> a condition variable, which Fibers cannot interrupt.

I see, thanks for explaining.

> Why not just replace ‘par-map’ with ‘map’?  That sounds easier and I
> suspect it doesn’t change much performance-wise.

The objective was to still be able to run parallel input fetching, but
you're right, a simple "map" is nicer.

> (There’s a 2nd use of ‘par-map’ in that file.)

Oh! Fixed too.

Thanks for the quick answer,

Mathieu