f



"Sayonara Tcl/Tk"

It seems that someone is really upset about Tcl/Tk.

http://forum.sqlitestudio.pl/viewtopic.php?f=16&t=333
0
saxo3800 (26)
4/29/2013 8:49:14 AM
comp.lang.tcl 23428 articles. 2 followers. Post Follow

3 Replies
618 Views

Similar Articles

[PageSpeed] 35

Στις 29/4/2013 11:49, ο/η saxo3800@gmail.com έγραψε:
> It seems that someone is really upset about Tcl/Tk.
>
> http://forum.sqlitestudio.pl/viewtopic.php?f=16&t=333
>

I think that he has a point regarding threads.

George
0
petasis (1405)
4/29/2013 9:02:23 AM
On Apr 29, 11:02=C2=A0am, Georgios Petasis <peta...@iit.demokritos.gr>
wrote:
> =CE=A3=CF=84=CE=B9=CF=82 29/4/2013 11:49, =CE=BF/=CE=B7 saxo3...@gmail.co=
m =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
>
> > It seems that someone is really upset about Tcl/Tk.
>
> >http://forum.sqlitestudio.pl/viewtopic.php?f=3D16&t=3D333
>
> 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.

-Alex
0
4/29/2013 5:07:49 PM
Στις 29/4/2013 20:07, ο/η Alexandre Ferrieux έγραψε:
> On Apr 29, 11:02 am, Georgios Petasis <peta...@iit.demokritos.gr>
> wrote:
>> Στις 29/4/2013 11:49, ο/η saxo3...@gmail.com έγραψε:
>>
>>> It seems that someone is really upset about Tcl/Tk.
>>
>>> http://forum.sqlitestudio.pl/viewtopic.php?f=16&t=333
>>
>> 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.
>
> -Alex
>

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.

George
0
petasis (1405)
4/29/2013 6:06:32 PM
Reply: