On Sun 23 Jun 2013 23:25, l...@gnu.org (Ludovic Courtès) writes:
> We have this (since 2010):
>
> # define SCM_SYSCALL(line)\
> do\
> { \
&g
l...@gnu.org (Ludovic Courtès) skribis:
> We have this (since 2010):
>
> # define SCM_SYSCALL(line)\
> do\
> { \
> errno = 0;
within asyncs, because asyncs might be
>>> called while the global state is in an inconsistent state, at least for
>>> data structures implemented in Scheme.
>>>
>>> What do you think?
[...]
>> However, with a fixed SCM_SYSCALL, the result is pretty much the same
us notifications. Thus I don’t have any
> particular problems with this implementation.
I looked more carefully, and agree that our current API is fine. It
makes it easy to handle signals in a different thread, if desired, or to
avoid the complications of multi-threaded programming and rely instead
(alarm 2)
>>
>> ;; This thread (the main thread) receives the signal. Yet,
>> ;; the EINTR returned by read(2) as called via `read-line'
>> ;; must be swallowed.
>> (let ((line (read-line (car in+out
>> (j
EINTR returned by read(2) as called via `read-line'
> ;; must be swallowed.
> (let ((line (read-line (car in+out
> (join-thread thread)
> (list signaled line)))
>
> This nicely reproduces the problem where fport_fill_input throws t
Hi Mark,
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> We have this (since 2010):
>>
>> # define SCM_SYSCALL(line)\
>> do\
>> {
Hi Ludovic,
l...@gnu.org (Ludovic Courtès) writes:
> We have this (since 2010):
>
> # define SCM_SYSCALL(line)\
> do\
> { \
&g
Hello Guilers!
We have this (since 2010):
--8<---cut here---start->8---
# define SCM_SYSCALL(line)\
do\
{ \
err
