[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some questions about concurrency (mostly)
From: |
felix . winkelmann |
Subject: |
Re: Some questions about concurrency (mostly) |
Date: |
Fri, 06 Nov 2020 11:57:15 +0100 |
> 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