On Wed, Oct 04, 2006 at 12:05:48PM +0200, Zoran Vasiljevic wrote: > I've been thinking about that... > Basically, what you try to avoid is to replicate common > C-idioms to Tcl because Tcl is not C after all. > > Would this include common threading paradigms like
> cond wait cond mutex ns_cond has exactly the same semantics and usage style as the C pthread_cond_*() functions which underly it, and thus is precisely as confusing and low-level as they are. This is annoying, especially when using ns_cond for the first time. However, it also has the important ADVANTAGE that the ns_cond implementation is simple, and that you know that ns_cond* and pthread_cond_* are in fact intended to work EXACTLY the same way. ns_cond has been extremely useful to me on the rare occasions when I needed it, but the average Naviserver user probably never uses it even once. And AOLserver (and thus Naviserver) has had ns_conf for many, many years. I bet the original ns_cond implementor couldn't think of a much better design, so he did the obvious simple thing: just wrap the ugly C APIs as is. 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. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/
