> > I could of course communicate between the threads using a global variable > and assignment, but this is nasty. Instead I thought of the following > interface: I would like to have two functions, let's call them "exposed" > and "snapshot". The first one would behave like identity (or values), > except that its evaluation would cause the snapshot value of the current > thread to be set. The second function would be used to retrieve the > snapshot value, so that it could be accessed from other threads. > > For example, I could define the evolution thread in the following way: > > (define evolution > (call-with-new-thread > (λ () > (channel-fold > (λ (state action) > (let ((state* (update state #;with action))) > (exposed state*))) > initial-state > EVENT-QUEUE)))) > > Then, I could access the state variable using the snapshot procedure, so > that -- for example -- I could use it in the drawing routine: > > (set-display-procedure! > (λ () > (draw! (visualization (snapshot evolution))))) > > What I would like about that solution is that even if the world was > updated much faster than the drawing routine could handle, the system could > remain responsive. (I also think that this interface would be nice with > time-constrained optimization algorithms, so that they could make the best > known solution available at any time) > > However, the problem is that -- while procedures have their properties -- > there seems to be nothing similar in the realm of threads. Normally in > similar cases I could use a thread-indexed hash table, but in the context > of multi-threading it would probably need to be protected by a mutex, and > it would likely slow things down. > > Any suggestions? >
I have found that SRFI-18 provides a pair thread-specific/thread-specific-set! that allows me to implement that interface. Hooray!
