Curt> I'm putting together a little network monitoring system in
Curt> scotty that sets up a separate job for each service on each host
Curt> that it monitors. These jobs run at regular intervals, and I'm
Curt> very careful to make them non-blocking; I use non-blocking I/O
Curt> while waiting for replies and, when no input is available, wait
Curt> with:
[snip]
Curt> so that other jobs can run while one is waiting for input.
You should not need to build such a loop. You should use fileevent
to wait read from sockets asynchronously and you should use the
asynchronous SNMP commands if your script uses SNMP. This will
make sure that the Tcl event loop will just do it right.
Curt> Unfortunately, I've run into a problem with starting the
Curt> jobs. My main program has a little loop that issues a series of
Curt> `job create' commands before it waits. It does an nbsleep of a
Curt> little over a second between the job create commands so that the
Curt> network traffic generated by this monitoring system is less
Curt> bursty.
Why don't you just put an after command around the job creation
command, e.g.:
after $delay {job create ....}
Things usually get much easier if you don't build your own loops but
instead use the Tcl loop to do all the event handling jobs. If you
want to delay the creation of job, simply use after to delay the job
creation command and let Tcl figure out when to evaluate it.
Curt> However, it appears that I can't start a job when another job is
Curt> running, even if that job is in an nbsleep. Is this indeed the
Curt> case?
No. This would be a bug.
Curt> And, if so, is there a way to do a `job create' that
Curt> doesn't run the job instantly upon creation, but delays a bit so
Curt> that I can get all my jobs created before any of them run?
See the example above.
Curt> BTW, I'm also interested in opinions on how I can run external
Curt> programs and send ICMP packets without blocking the entire
Curt> application.
External programs are easy (at least on UNIX): You open a pipe to the
program and you use fileevent to read the output from the program.
proc getyow f {
if [eof $f] {
close $f
} else {
puts [gets $f]
}
}
set f [open "|ruptime"]
fileevent $f readable "getyow $f"
The icmp command is curently always blocking. However, you can group
multiple destination into a long list of destinations, which reduces
the total amount of blocking times. However, this is not really what
you were looking for.
Juergen
Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283)
-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.