Στις 29/4/2013 20:07, ο/η Alexandre Ferrieux έγραψε:
> On Apr 29, 11:02 am, Georgios Petasis <peta...@iit.demokritos.gr>
>> Στις 29/4/2013 11:49, ο/η saxo3...@gmail.com έγραψε:
>>> It seems that someone is really upset about Tcl/Tk.
>> I think that he has a point regarding threads.
> Sure. Though I'm curious to know what specific problem of his is so
> much better served by explicit locks and shared vars than by message
> passing, given the context. It's not as if he was worried by lost
> nanoseconds in mutex contention.
I think that there are a number of "gray areas" in the current threading
model that make some applications really complex, if not impossible.
Reusing a resource that was created in one thread (like a large hash
table, i.e. a 2 GB one) is very difficult. Having to reload the
application in all threads, is also complex. Working with threads at the
C level, is a nightmare.
A quick example that comes in mind, is the integration of threads with
apache rivet I tried last September. I lost interest because:
a) The interpreter cannot be used in any way from any other thread other
than the one that created. But apache httpd does not care about this,
and sends requests from any possible thread. This means that I have to
create a thread pool at the C level, very close to what the thread
extension has done. Piece of cake? :D
(And I haven't even considered how data written by puts in memory
channels will be shared with apache threads...)
b) Then I realized that even if I had a threaded rivet, I could not
share resources. I could not have a hash table shared by all threads.
Perhaps you are right and I am wrong, but I think that it is very
difficult to use threads in tcl. And the example of accessing a tcloo
object from another thread is a good one I think.