Updated 2012-08-28 00:48:08 by LkpPo ▲

Martin S. Weber
 Ephaeton at gmx dot net

 a person who's been away from Tcl for too long...

Wiki stuff:

Next to come:

Other:

This will be moved to another page once I find a good name for it.

msw suchenwi: I managed to shape up the script which is giving me vwait problems

* suchenwi can't look - busy with paywork .}

msw have a look at wiki://MSW, there's code and output from a run showing what I'm getting mad about :)

msw ...once you have time that is.

msw with tclsh running you just don't get the code to fuck up ... with tk it's piece of cake

msw Suppose you'd need to tokenize each run with own target variable etc. so it doesn't try to be multiply in the same proc

msw you others are well invited to have a look and tell me what I did wrong, too :)

arjen I am sorry: ight now I have my own things to get mad about ;)

msw oh, there's no pressure here, I've found a(n uberugly) workaround for my problem

msw Just for the usual cursing/"what's NOT possible"/things to avoid - notebook..

suchenwi msw: maybe you should just disable thew button when clicked, and re-enable it when bexec is done...

msw suchenwi: that's what I'm doing (a bit different, using a grab on a label saying have patience)

suchenwi As a single global variable bexec_result holds the results, two "parallel" bexecs are only guaranteed to make trouble.

msw suchenwi: but it's definitely a (n ugly) workaround

msw suchenwi: that's why I'm locking

msw suchenwi: and the locking is exposing the actual problem..

msw suchenwi: after the command is done, and the vwait returns, the proc is twice at the same position - before the acquire-lock part

suchenwi Maybe just to use ::bexec_runs to signal whether bexec is ain progress: if $::bexec_runs return

msw suchenwi: version #1 was doing that kind of ...

suchenwi Initializi to 0, set to 1 in the first bexec call, reset to 0 after the vwait.

msw if {$bexec_runs} then {vwait bexec_runs} ..

msw I should maybe add after idle to the vwait

suchenwi You can't vwait in two places for the same variable.

msw that's the dilemma :)

suchenwi But you can check its value and return early.

msw so I need to tokenize if I want to have the stuff be able to run in parallel

msw like vwait [token-var], append result to [token-var] etc.

suchenwi Yes - sort of like the http package does it.

msw my manpage doesn't mention that you cannot vwait on the same var twice btw.

msw (8.3)

suchenwi Hm.. maybe you can, but it seems conceptually unclear to me - which vwait fires first, etc.

* suchenwi meeting

msw basically it should be fifo

msw but well, some core-savvy wants to comment ? :)

msw 8.4 vwait man doesn't mention it either

nem vwaits stack - I would assume that it would be a filo - last vwait would fire before first

msw well, event _queue_, would've supposed an append each time, but that doesn't matter ...

msw I wouldn't care about the order ...

msw if the events would be ok, but it seems broken (check the output on wiki.tcl.tk/msw, bottom of page)

* dkf back

suchenwi Donal: can two vwaits wait for the same variable?

dkf Yes

suchenwi And in what order are they released?

dkf Strict stack order

suchenwi But with "parallel" events, is there a stack order?

dkf There's always a stack order

dkf 'Cos we're all implemented in C...

suchenwi Ah, right :)

dkf The problem with msw's code is that it is trying to use stack-based operation with event handling

msw I've the feeling all I need is a closure and it'll work :p

dkf This is the sort of thing that http://wiki.tcl.tk/1255 warns against

dkf Actually, you need continuations ;)

msw ok, gimme :)

dkf But in their absence, what you need to do is to restructure your code so that instead of bexec returning the result, it takes a script which it hands off the result to when the background execution is done.

dkf With that done, you can rewrite your code to be completely free of calls to vwait and have it work.

msw ok, what I called "tokenize".

msw er wait, I need one vwait at least ... (should work in tcl, too)

dkf If it is to work in standard Tcl, then you add a [vwait forever] in your main script

msw hmm but it's used like ..

msw < synchronous > ... use "bgexec" < .. more synchronous >

suchenwi postprocess [bexec $input]

msw ah ok, when I have to pass a script anyways ..

msw grmpf, mental recursion coming up.

msw it's actually <synch> (bgexec + synch) * n <synch> .. the * n is going to be fun.

msw pity I need both stdout and stderr, split and "live" while the command runs... minus that requirement, would be dead easy..

* msw figures that if it was obvious, wouldn't need CODE to realise.

dkf Sorry it took so long to write, but there was quite a bit to read ;)

dkf s/read/write

nem is the if {[gets $f line] == -1} { .. ok? I usually use if {[catch {gets $f} line] || [eof $f]} { ...

nem I seem to remember being taught to do that a long long time ago

dkf the gets line really is ok

dkf Since we're not blocking

nem Ah, ok

dkf And eof results in -1 result

msw was just thinking the same, but the old version used read first then checked with eof

dkf Technically, it's the close that could fail

dkf The gets version should work as well

nem Thinking about it the catch/eof combo might possibly fail to read the last line

dkf And I'm singularly unworried about malicious code; we're running a general command here after all ;)

dkf nem: Do you do incomplete last lines in your files?

nem not usually - but it's a possibility

dkf Notice the total lack of vwait in that code

nem vwait is eeeevil.

msw yeah, I noticed.

msw if it's eeeevil, tcl should kick it out :)

dkf vwait is only evil if you have reentrant code, but reentrant vwait is a real problem

dkf Sometimes you need it

dkf (e.g. modal dialog boxes)

nem modal dialog boxes are eeevil

dkf Won't argue with that ;)

nem tk_messageBox usage of vwait internally has bitten me several times (to the point where I don't use it any more)

dkf But sometimes the client wants their soul sold to the devil anyway

dkf It's OK, but you have to take care to stop *two* simultaneous runs of the same code

msw vwait should be expanded so that this works too :)

MSW (broken) version
 set ::bexec_runs 0
 set ::bexec_result ""
 set ::bnum 0

 proc bexec what {
        global bexec_runs bexec_result bnum
        incr bnum
        set fname [file join $::env(HOME) tmp cmd_run_lock_$::env(USER)_[pid]]
        while {[catch {set fp [open $fname {WRONLY CREAT EXCL}]}]}  {
                        puts stderr "($bnum) Lock busy, will retry."
                        after 200 "set ::retry 0"
                        vwait ::retry
        }
        puts stderr "($bnum)Got the Lock for \"[string range $what 0 99]...\"."

        # reset results
        set ::bexec_result ""
        puts stderr "Executing $what..."
        set bexec_runs 1
        set f [open |$what]
        #fconfigure $f -translation none
        fileevent $f readable [list bexec_read $f]
        vwait bexec_runs
        file delete -force [file join $::env(HOME) tmp cmd_run_lock_$::env(USER)_[pid]]
        puts stderr "($bnum)Released the Lock for \"[string range $what 0 99]...\"."

        return $bexec_result
 }

 proc bexec_read {f} {
        set data [read $f]
        if [eof $f] {
                close $f
                set ::bexec_runs 0
        }
        append ::bexec_result $data
 }

 # demo1:
 set tfile [open tst.sh w]
 puts $tfile {#!/bin/sh
 echo "output1"
 sleep 3
 echo "output2"}
 close $tfile

 puts [bexec "sh tst.sh"]
 puts [bexec "sh tst.sh"] ;# <-- this one will wait.

 # demo2:
 pack [button .b -text "run" -command {puts [bexec "sh tst.sh"]}] -expand 1 -fill both

Output:
 (1)Got the Lock for "sh tst.sh...".
 (1)Executing sh tst.sh...
 (1)Released the Lock for "sh tst.sh...".
 output1
 output2

 (2)Got the Lock for "sh tst.sh...".
 (2)Executing sh tst.sh...
 (2)Released the Lock for "sh tst.sh...".
 output1
 output2

 (3)Got the Lock for "sh tst.sh...".
 (3)Executing sh tst.sh...
 (3)Released the Lock for "sh tst.sh...".
 output1
 output2

 (4)Got the Lock for "sh tst.sh...".
 (4)Executing sh tst.sh...
 (5) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 (6) Lock busy, will retry.
 # ad infitum... lockfile never goes away.

DKF VERSION
 set ::bexec_runs 0
 set ::bexec_result ""
 set ::bnum 0

 proc bexec {what handler {uid -1}} {
   global bexec_accum bnum
   if {$uid == -1} {
      set uid [incr bnum]
   }
   set fname [file join ~ tmp cmd_run_lock_[pid]]
   if {[catch {open $fname {WRONLY CREAT EXCL}} fp]} {
      puts stderr "($uid) Lock busy, will retry."
      after 200 [list bexec $what $handler $uid]
      return
   }
   set f [open |$what]
   set bexec_accum($uid) {}
   fileevent $f readable [list bexec_read $f $uid $fname $handler]
 }
 proc bexec_read {f uid fname handler} {
   global bexec_accum
   if {[gets $f line] == -1} {
      close $f
      file delete -force $fname
      uplevel #0 $handler [list $bexec_accum($uid)]
      unset bexec_accum($uid)
      return
   }
   append bexec_accum($uid) $line \n
 }
 # demo1:
 set tfile [open tst.sh w]
 puts $tfile {#!/bin/sh
 echo "output1"
 sleep 3
 echo "output2"}
 close $tfile

 bexec "sh tst.sh" puts
 bexec "sh tst.sh" puts ;# <-- this one will wait.

 # demo2:
 pack [button .b -text "run" -command {bexec "sh tst.sh" puts}] -expand 1 -fill both

Output:
 (2) Lock busy, will retry.
 (2) Lock busy, will retry.
 (2) Lock busy, will retry.
 (2) Lock busy, will retry.
 (2) Lock busy, will retry.
 (2) Lock busy, will retry.
 (2) Lock busy, will retry.
 (2) Lock busy, will retry.
 (2) Lock busy, will retry.
 (2) Lock busy, will retry.
 (2) Lock busy, will retry.
 (2) Lock busy, will retry.
 (2) Lock busy, will retry.
 (2) Lock busy, will retry.
 (2) Lock busy, will retry.
 output1
 output2

 output1
 output2

 (4) Lock busy, will retry.
 (4) Lock busy, will retry.
 (4) Lock busy, will retry.
 (4) Lock busy, will retry.
 (4) Lock busy, will retry.
 (4) Lock busy, will retry.
 (4) Lock busy, will retry.
 (4) Lock busy, will retry.
 (4) Lock busy, will retry.
 (4) Lock busy, will retry.
 (4) Lock busy, will retry.
 (4) Lock busy, will retry.
 (4) Lock busy, will retry.
 (4) Lock busy, will retry.
 output1
 output2

 (5) Lock busy, will retry.
 (5) Lock busy, will retry.
 (5) Lock busy, will retry.
 output1
 output2

 output1
 output2

Category Person