On 04.10.2006, at 16:52, Andrew Piskorski wrote:
Designing better, high level, Tcl-ish APIs is non-trivial. And if you're going to design some better high level API for waking up a thread, why even pollute your thinking with low-level "condition variable" stuff at all? Zoran, I think you've already got some nice message passing style stuff in your Threads extension, maybe it would make more sense to add some friendlier "Heh thread X, wake up, you've got work to do now!" style API there? And if so, I'd say leave ns_cond alone, it's just a low-level wrapper around pthread_cond_*, and that's fine. Futzing with it sounds likely to be wasted effort at best, and perhaps a source of very tricky destabalizing bugs at worst.
Every word true. I just gave it as an example to illustrate what Stephen ment by "doing the Tcl way". I know that exposing the low level C API to the Tcl level isn't going to please everybody. And this is true. Just, to get "some" things right, you need to step out of the circle and offer someting completely different. Out of the experience with the tcl threading extension I can say that people *mostly* just use it in a most-simple fashion: post scripts to threads and wait for results. But, ocasionally, they need "alternate" way of synchronization and that is where mutexes and condvars come into play. And, I must say, I really do not know how to "solve" that in a different way. I'm not even going to try. Speaking of that... the naviserver users (either current or future) may really benefit of the "alternate" thread communication I did for the Tcl threading extension (basically message-passing thing), but this is another story.
