response 1 of 1:

Sep 11 04:07 UTC 2007

Hey cross, mcnally, or anyone else that has a clue when it comes to
programming. I was thinking nharmon probably had a valid issue with me
killing any hung threads. However nharmons solution attempted in thread
88 just plain fucking sucks. Here is a recap of this fags solution

 #!/usr/bin/ruby
    pid = fork do
      Signal.trap('HUP') do
         Process.kill(-1, Process.getpgrp())
      end
      threads=[]
      threads[0]=Thread.new %x{/usr/local/bin/pico}
      loop do
        sleep 20
      end
    end
    Process.detach(pid)

I'm really not that threads master, but I know enough to
1)Properly exit my threads

2)When to use fork and when not to use fork. I'm still not too sure what
nharmon(ie the dumbass of this forum) was trying to accomplish by
forking then calling thread. The only time I've ever used fork is to
sync two processes via pipes or use it for error trapping (like in my
tel nuker).

3)When to use threads and when not to. Again, I'm still drawing a blank
on why nharmon only uses threads once. If this idiot was trying to do an
example of killing everything, he could have done it without threads.
The only time I seem to be using ruby threads is when I'm trying to
emulate parallelism.

Now, couldn't I use use something like Timeout and rescue to kill any
delinquent threads? If I would use captain hoseheads solution, I would
hose ALL my threads. Even the threads that I don't want hosed. There are
a lot of cases that I want to kill some threads, but not all my threads.

Besides, I don't think signals really exist on Windows XP. However,
there might be some kind of signal emulation (via cygwin) on Windows.
This brings up a second point. I don't think I would mess with ruby
fork. I'm assuming if ruby is meant to be portable like perl, then this
means that ruby emulates fork() via threads (like what perl does).