Re: [9fans] dial and time out

["Mathieu L." <lejatorn@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

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.

[-- Attachment #2: Type: message/rfc822, Size: 4002 bytes --]

From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] dial and time out
Date: Thu, 10 Sep 2009 05:34:54 -0400
Message-ID: <0224fcf7437ae954977afd3a2a53bdec@quanstro.net>

> 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