while thread is multi thread it's still a single process if that makes any sense, meaning if the thread::send -async is waiting the next one waits as well
there for tpool you'll notice that after 10000 doesn't have any effect on it while it does on thread for those who want it.
you could say it is more parallel
Code:
namespace eval tpool_test { package require Thread tsv::set THREAD master [thread::id] if {![info exists pool]} { variable pool [tpool::create -minworkers 1 -maxworkers 10 -idletime 120 -initcmd { package require Thread proc putserv {text {arg {}}} { thread::send -async [tsv::get THREAD master] [concat putserv [list ${text}] ${arg}] } proc tpool1_proc {nick host hand chan arg} { after 10000 putserv "PRIVMSG #support :REPLY_TPOOL1:[clock seconds]" } proc tpool2_proc {nick host hand chan arg} { putserv "PRIVMSG #support :REPLY_TPOOL2:[clock seconds]" -next } }] } proc tpool1_proc_pub {nick host hand chan arg} { variable pool tpool::post -nowait $pool [list tpool1_proc $nick $host $hand $chan $arg] putserv "PRIVMSG $chan :TPOOL1_DELAY:[clock seconds]" } proc tpool2_proc_pub {nick host hand chan arg} { variable pool tpool::post -nowait $pool [list tpool2_proc $nick $host $hand $chan $arg] putserv "PRIVMSG $chan :TPOOL2_NODELAY:[clock seconds]" } bind pub -|- !tpool1 [namespace current]::tpool1_proc_pub bind pub -|- !tpool2 [namespace current]::tpool2_proc_pub}great i'll give it a shot, one remark to transport variables you better, well better they made a lib to share it so and you never know when you're about to change it, ..so use tsv::set & tsv::get and putserv "text" -next << forgot this oneTcl's threading model is one interpreter per thread. An interpreter is like starting a fresh tclsh, without loading any extensions. I doesn't know about the "parent"s variables or commands, and so Thread interpreters don't know commands from the eggdrop extension or variables. You have to design your own message-passing ([thread::send -async]) so that the threads ask the main thread to do something eggdropish. Example:The returned thread knows how to putserv (by asking the mainthread asynchronously to do it).Code:
proc createusefulthread {} { set t [thread::create {thread::wait}] thread::send $t [list set ::mainthread [thread::id]] thread::send $t { proc putserv {text} { thread::send -async $::mainthread [list putserv $text] } } return $t}
Note: I set a variable in the "child" threads called $::mainthread instead of using thread-shared data, because it will always stay the same and will only ever be read, never written or changed. In general, you should consider using thread shared data if this is not the case, of course.
Code:
proc createusefulthread {} { set t [thread::create {thread::wait}] tsv::set thread main $t thread::send $t { proc putserv {text {arg {}}} { thread::send -async [tsv::get thread main] [concat putserv [list ${text}] ${arg}] } } return $t}well i posted it to eggdrop cause i wasn't sure if it belonged in eggdrop or ttrace, or tcl but it's great that you posted the problem in the right place, well i wasn't suggesting you change the source merely posted a quick hack to the problem.This is a fault in ttrace.tcl, part of the Thread extension. While it perfectly makes sense for eggdrop to have a global version variable, it's inappropriate and arrogant for a script to abuse such a common name to store a temporary value for one-time use.
We won't change eggdrop's variable name due to compatibility reasons, so users should modify the ttrace.tcl script, which is easier than modifying eggdrop source anyway. We have filed a bug report for Ttrace in the hope that it will get fixed.
Statistics: Posted by Ofloo — Fri Jul 23, 2010 6:01 pm
]]>