in Glib, each thread can have its own independent loops.

Sure. But having a bunch of threads share a single "global" event loop is rather harder. That's why it's preferable (imo) to get a module to manage the mess (e.g. POE), rather than trying to reinvent the wheel. :-)

It's like in a fork...should changing scalars in a fork affect the parent? No. Same with threads. Communication channels....shared vars, filenos make the communication easier, but it is still up to the parent or sibling thread to actively read another thread......no forced broadcast allowed. You could set it up that way if you wanted. (Like a family yelling at one another :-))

---

I'm not really a human, but I play one on earth My Petition to the Great Cosmic Conciousness

Ive been looking at POE wheel, which will make my job a lot easier and will give me a lot more power within Tk. however for the current setup I have I think using a timmer will be just as good (I only need to check a shared array every couple of seconds) Time HiRes (setitimer) will work fine. with this however comes a complaint from my compiler that 'your vendor has not defined Time::HiRes macro ITIMER_VIRTUAL'
with the following code taken from the HiRes example set

use Time::HiRes qw(tv_interval);

  use Time::HiRes qw ( setitimer ITIMER_VIRTUAL time );

  $SIG{VTALRM} = sub { print time, "\n" };
  setitimer(ITIMER_VIRTUAL, 10, 2.5);
[download]

I am Running Active State Perl 5.88 build 819 on a XP, with HiRes 1.86
any pointers would be greatly apprenticed, however if HiRes will not run on my system I will rewrite with POE
thanks Skywalker