Re: Some questions about concurrency (mostly)

[felix . winkelmann]

> 1. Are there any problems with creating a condition (as in exception,
>    not srfi-18 condition variable) in one thread and raising it in one
>    or more other threads?

No problem here, I'd say, data can be freely exchanged between threads,
since they share a global address space. A condition object is just a
data structure.

> 2. In my application I'm running a thread that reads from a TCP port and
>    dispatches frames back to the main thread using a mailbox (from the
>    mailbox egg). I'm also running a separate thread that sends a
>    heartbeat frame back over the TCP connecion every 30s. This works
>    fine, but I've noticed that after a while (this seems to happen
>    consistently after the first heartbeat has been sent) I cannot press
>    Ctrl-C in the terminal to stop the application. However, as soon as
>    the dispatcher thread reads an incoming frame, the process is
>    interrupted. I assume this has something to do with blocking threads?
>    Is there something I can do about it?

Is this in a compiled application or inside csi? If the former, do you install
a handler for SIGINT?

> 3. I'm new to dynamic-wind. If I wanted to create a general form for
>    executing a thunk protected by a mutex, would this be a good idea?
>
>      (define (with-lock mutex thunk)
>        (dynamic-wind
>            (lambda () (mutex-lock! mutex))
>                thunk
>                (lambda () (mutex-unlock! mutex)))))
>
>    I read somewhere that the before- and after-guards might execute
>    multiple times, but then again I'm not really sure under what
>    circumstances so I might be way off.

Whenever the continuation is re-invoked, the before/after thunks
will be called on entering the dynamic context in which the 2nd
thunk above will be executed, and the before/after thunks will
always be called in pairs, so your approach looks fine to me.

For example, load this into csi:

(define k0 #f)
(define k1 #f)

(define (foo)
  (call/cc
    (lambda (k)
      (dynamic-wind
        (cut print 'before)
        (lambda ()
          (set! k0 k)
          (call/cc
            (lambda (k2)
              (set! k1 k2)
              #f))
          (k 99))
        (cut print 'after)))))

#;1> (foo)
before
after
99
#;2> (k0 100)
100
#;3> (k1 101)
before
after
99

dynamic-wind is powerful, but can be very confusing, expecially
if you mix in threads and exceptions. Better try to keep the
control-flow of your code simple.

>
> 4. The srfi-18 thread scheduler seems to behave slightly differently
>    when running compiled code and in csi. Is that correct?

This depends on what you mean with "slightly". Interruption
of running threads (because the time-slice is used up) will happen
at different points in interpreted vs. compiled code - compiled code
is more compact and has of course completely different timing
behaviour. Can you elaborate on what you mean with "differently"?


felix