[9fans] dial and time out

[9fans] dial and time out

[Mathieu L.]

Hello 9fans,

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.

Is that the right way to go? If yes, can anyone think of an already
existing example I can look at?

Mathieu

Re: [9fans] dial and time out

[erik quanstrom]

> 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

Re: [9fans] dial and time out

[Mathieu L.]

[-- 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

Re: [9fans] dial and time out

[erik quanstrom]

> 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.

one can use ioproc(2).  though i tend to go for procs.

this is because i have a hard time understanding why
csp (and thus safety) wouldn't generally be used instead.
and when csp techniques aren't going to cut it, i find
it easier to understand a small amount of explicit locking,
because the interesting bits of contention are well-marked.

- erik

Re: [9fans] dial and time out

[Sape Mullender]

Threads are great for preventing race conditions.  I agree.

Many Plan 9 applications (ria, acme, etc.) use a central proc with lots of
threads doing the real work of manipulating the state of the application.
No locks are required, because the threads explicitly yield by doing
channel io or calling yield().

IO is done by single-threaded procs, almost one per file descriptor.
These IO threads typically run on the lines of:
	void
	ioproc(void *a)
	{
		for(;;){
			read(fd, ...)
			send(channel, ...)
		}
	}
to send what was read to a central-proc's worker thread.

	Sape


> From: lejatorn@gmail.com
> To: 9fans@9fans.net
> Reply-To: 9fans@9fans.net
> Date: Thu Sep 10 11:57:50 CES 2009
> Subject: Re: [9fans] dial and time out
>
> 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.
>
>
> — 2/

[9fans] dial and time out

[Sape Mullender]

If you really mean thread and not proc, then what you suggest won't work.
You can't kill a thread that's in the OS without killing the proc
conyaining the thread (thereby killing all the other threads as well).
You can have the proc catch notes and send a note to the proc which
will interrupt any system call, thereby pulling the thread out of
the dial.

A more elgant way to do this would be to use ioproc(2), or to
create procs explicitly to do the dial I/O.

	Sape

> From: lejatorn@gmail.com
> To: 9fans@9fans.net
> Reply-To: 9fans@9fans.net
> Date: Thu Sep 10 11:38:50 CES 2009
> Subject: [9fans] dial and time out
>
> Hello 9fans,
>
> 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.
>
> Is that the right way to go? If yes, can anyone think of an already
> existing example I can look at?
>
> Mathieu
>

Re: [9fans] dial and time out

[Mathieu L.]

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

Yes, I did mean thread, and I hadn't realized this would kill all the
threads.  I'll try with ioproc then, thanks for the example.

Mathieu

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

From: Sape Mullender <sape@plan9.bell-labs.com>
To: 9fans@9fans.net
Cc: 9fans@9fans.net
Subject: [9fans]  dial and time out
Date: Thu, 10 Sep 2009 11:57:02 +0200
Message-ID: <c194c1043ecbf8810c546dbd2d616c75@plan9.bell-labs.com>

If you really mean thread and not proc, then what you suggest won't work.
You can't kill a thread that's in the OS without killing the proc
conyaining the thread (thereby killing all the other threads as well).
You can have the proc catch notes and send a note to the proc which
will interrupt any system call, thereby pulling the thread out of
the dial.

A more elgant way to do this would be to use ioproc(2), or to
create procs explicitly to do the dial I/O.

	Sape

> From: lejatorn@gmail.com
> To: 9fans@9fans.net
> Reply-To: 9fans@9fans.net
> Date: Thu Sep 10 11:38:50 CES 2009
> Subject: [9fans] dial and time out
>
> Hello 9fans,
>
> 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.
>
> Is that the right way to go? If yes, can anyone think of an already
> existing example I can look at?
>
> Mathieu
>