Greywolf <greywolf@starwolf.com> writes:

> NJW> For UP, it's not a restriction, it's a deliberate property of SAs. In
> NJW> general, the number of SA LWPs in userspace should always be less than
> NJW> or equal to the number of CPUs in the system.
> 
> ??
> 
> Do you mean "active SA LWPs"?

I think that what you have in mind by "active" is what I had in mind
by "in userspace", which is "executing instructions in user
mode". This is the point at which we have to remember that the system
only ever *pretends* to run several LWPs at the same time; it's
actually time-multiplexing them.

> Otherwise, wouldn't the restriction mean that sa_create (or whatever
> it's called) would automatically fail, and SA LWP would be completely
> useless...?

If a process can call sa_enable(), then it's running in userspace on a
processor, and while it is doing so, no other LWP is running in
userspace on that processor.

> Oh, can I also surmise -- on a slightly different tangent -- that the
> primary use thus far for SA/LWP is more or less for function-while-
> display (under X, for example (i.e. XMMS/mozilla), so that stuff can just
> run in the background without the overhead of fork()/IPC?

Well, function-while-display can be achieved without threads at all by
a sufficently fine-grained event loop, and many programs operate that
way. Some people find writing such programs with threads to be
conceptually easier. The other purpose of threads is to exploit
concurrency by telling the system about multiple operations to perform
that can be done in parallel; at the moment, this is mostly I/O
concurrency (and I/O concurrency with computation, e.g. xmms doing
"I'll go decode this MP3 while you fetch that data over the network"),
but multi-CPU concurrency is certainly a goal.

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

        - Nathan