a silly question about concurrent propagators

[Raphael Collet]

Aurélien Campéas wrote:
> While we are doing some 'final touches' (read : last-minute debugging
> of vital functionality) to a dumbed-down (non-nestable) version of the
> computation space concept for inclusion in PyPy (see the pypy project
> at : http://codespeak.net/pypy/) I also have to polish the technical
> report that explains what we did, and why, and I have a hard time
> remembering the rationale behind constraint propagators running in
> their own threads. (I'am quite sure I asked Raphael at some point but
> I didn't record reliably his answer, whatever it was)

I remember we discussed a lot about this design issue, but I do not 
remember whether we reached a definitive answer to the question...  Here 
are a few elements that may help.

If you're interested in "pure" constraint programming, then you don't 
need threads.  All you need is something (read: an object) that executes 
the propagators until they reach a fixpoint.  In Gecode, this task is 
done by the object that implements the computation space.

Now, if you want to run preemptive (Python) code inside a space, it's a 
different story.  You need something like that if you want to use spaces 
for logic programming.  The logic program inside the space should stop 
when a nondeterministic choice has to be made, and let the search engine 
(outside the space) decide what to do.  Or the logic program could be 
encoded as a data structure that is fed to a solver, possibly written in 
Python (and single-threaded).

If you want to use logic variables for dataflow synchronization (inside 
computation spaces or in the main program), then you need explicit 
threads, IMO.  Being able to run arbitrary Oz code inside spaces is what 
led the designers of Oz to this general concept of computation spaces.


Don't hesitate to ask for more if it's not enough ;-)

Regards,
raph