it seemed safer at first if I didn't have to worry about the procs
preempting each other (and appart from that dial() bottleneck, I don't
need them to), that's why I started with threads. I was thinking of
sticking to threads and not using procs until I really do need them. But
yeah, no real good reason not to switch to procs if that's the best way
to go in that case.
Mathieu.
--- Begin Message ---
> I have a bunch of threads, simply scheduled with yield() at the moment
> (I'll use alt later on), and each of them is calling dial() at some
> point. I don't want the other threads to wait for "too long" when one
> of them is blocked on a dial() that will eventually time out.
> So I was thinking, for each of them, of creating a proc which would
> be used as a timer; it would be created just before the call to dial,
> wait for some time, and then kill the dial()ing thread. And as mechiel
> suggested, the dial()ing thread would also be set to kill the timer
> after it successfully dialed, hence not being killed if it was fast
> enough.
what's the reason for not using procs?
- erik
--- End Message ---
