Hi,
Olivier Dion skribis:
> If we got interrupted while waiting on our condition variable, we unlock
> the kernel mutex momentarily while executing asynchronous operations
> before putting us back into the waiting queue.
>
> However, we have to retry acquiring the mutex before getting back into
Hi,
Andrew Whatson skribis:
> Forcibly closing file descriptors like this shouldn't be necessary if
> the application has properly opened descriptors with the FD_CLOEXEC
> flag. It would be good to get input from some more experienced Guile
> hackers on the potential consequences of this change
Hi,
Ludovic Courtès skribis:
> Ludovic Courtès skribis:
>
>> Consider this code:
>>
>> ;; https://issues.guix.gnu.org/58631
>> ;; https://github.com/wingo/fibers/issues/65
>>
>> (define loss
>> (make-vector 100))
>>
>> (let ((tag (make-prompt-tag "my prompt")))
>> (define handler
>>
On Sun, 20 Nov 2022, Ludovic Courtès wrote:
> Did you try to come up with a reproducer? That would be awesome but I
> guess it’s hard because you need to trigger EINTR at the right point.
With a stress test in guile-parallel. Very hard to reproduce indeed.
You can also reproduce it with `ice-9
On Sun, Nov 20, 2022 at 06:24:57PM +0100, Ludovic Courtès wrote:
> Hi,
>
> Andrew Whatson skribis:
>
> > Forcibly closing file descriptors like this shouldn't be necessary if
> > the application has properly opened descriptors with the FD_CLOEXEC
> > flag. It would be good to get input from som
Ludovic Courtès wrote:
>
> Andrew Whatson skribis:
>
> > Forcibly closing file descriptors like this shouldn't be necessary if
> > the application has properly opened descriptors with the FD_CLOEXEC
> > flag. It would be good to get input from some more experienced Guile
> > hackers on the poten
