Subject: Re: rough SA patch (works on SMP)
To: Ron Roskens <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 06/24/2003 09:20:56
On Tue, 24 Jun 2003, Ron Roskens wrote:
> On Tue, 24 Jun 2003, Nathan J. Williams wrote:
> > Greywolf <firstname.lastname@example.org> writes:
> > > Opinion survey: Would dump(8) benefit from SA/LWP?
> > Remember that SA/LWP is just a particular implementation of
> > threads. Don't think about the SA/LWP stuff so much if you're writing
> > a program; think about the threads, and the places where there's
> > concurrency to be had. The dump(8) program is mostly about sucking
> > data off of a filesystem and onto something else, and the kernel's
> > own I/O concurrency is sufficent for it, I think. Threads might be
> > useful if, for some reason, you wanted a single invocation of the
> > dump(8) program to dump multiple filesystems to multiple targets at
> > the same time.... but since you can do that with multiple standard
> > dump(8) processes, I don't think there's a benefit to that compexity.
> So a program like syslogd might benefit from threads, since it has
> multiple inputs and multiple outputs?
Not necessarily. syslogd works quite well with a select or poll loop.
Another consideration is how much state you need to keep for each
transaction. syslogd just routes packets, which is rather simple.
Something like a web server, though, can have a lot of state wrapped up in
a connection, and interrupting it can be a pain. Especially if you have
modules that are handling part of the processing (where writing a do-what-
you-need-and-return type routine would involve everyone doing it) it
probably us just easier to give a task a thread.