Re: A timely question on interrupted system calls

[mark . d . witmer]

address@hidden (Ludovic Courtès) writes:

> address@hidden skribis:
>
>> I followed the thread a few days ago on @guile-dev about SCM_SYSCALL and
>> was grateful I hadn't run into any problems with it. But now I have!
>
> Excellent.  :-)
>
>> I'm working with an event loop for my X bindings that polls a socket for
>> availablity using `select'. Meanwhile, I have a repl server running in
>> another thread. When something connects to the server, the call to
>> `select' get interrupted and throws a system error. In the following
>> code the catch expression doesn't catch the system error:
>
> Could it be that it’s actually the other thread that gets EINTR?

Thanks for the insights. I figured out what I was doing wrong... it was
actually a result of my not understanding dynamic states well enough.

I had some parameters in use in the main thread that I wanted to share
with the repl thread, so I figured it wouldn't hurt to do something like
this:

(define dynamic-state (current-dynamic-state))
(with-dynamic-state dynamic-state
  (make-thread
     (lambda ()
       ... start repl ...)))

But of course that was the cause of all my problems. The tag that
`throw' uses when it aborts to the catch prompt is captured as an
argument to a function stored in a fluid, so it's sensitive to
manipulations of the dynamic state like this. Basically, the system
error was throwing to a different (make-prompt-tag "catch") than the
(make-prompt-tag "catch") my catch was set up to handle. D'oh! It didn't
really have much to do with system calls or errors at all.

I think the correct way to make parameters in different threads refer to
the same object is like this:

(define my-param-value (my-param))
(make-thread
  (lambda ()
    (parameterize ((my-param my-param-value))
     ...)))

It feels a bit hackish, but sometimes I like the nested dynamic scope
behavior of parameters even when I don't want the thread sandboxing.

-- 
Mark Witmer