Re: [9fans] vfork and paging

Re: [9fans] vfork and paging

[rob pike]

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

But vfork was about processes. It was an attempt to make
fork/exec cheaper by avoiding wasting the copy time for
the pages that were going to be thrown away by the exec.

-rob


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

From: forsyth@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] vfork and paging
Date: Mon, 1 Oct 2001 15:01:24 +0100
Message-ID: <20011001135648.50FFF19B02@mail.cse.psu.edu>

>> the BSD approach is poor.  unfortunately, people mimic it.
>> i can only assume that one or more textbooks wrote it up.

> Our approach was different, as Plan 9 users will appreciate.
> Processes, rather than being a scourge to be avoided or
> perhaps hidden behind an advertising adjective, are the
> solution to many a systems problem and should be embraced.

i was referring to the paging implementation but it's true of
the approach to processes too.

Re: [9fans] vfork and paging

[Douglas A. Gwyn]

rob pike wrote:
> But vfork was about processes. It was an attempt to make
> fork/exec cheaper by avoiding wasting the copy time for
> the pages that were going to be thrown away by the exec.

That's why copy-on-write was relevant; with a working
copy-on-write, fork is about as cheap as vfork.
In the Software Tools, which had to be hosted on top of
a variety of very hostile mainframe OSes, fork/exec was
replaced by spawn (with parameters).  Not as clean, but
more readily emulatable.

Re: [9fans] vfork and paging

[David Gordon Hogan]

> You're not dreaming, but webfs is not what you might call functional
> yet.  It's unclear whether it'll ever be.  I don't know who uses it here.

	%g ls -ld /sys/src/cmd/webfs
	d-rwxrwxr-x M 8 dhog sys 0 Oct  1 09:44 /sys/src/cmd/webfs

Thanks for the vote of confidence :-)

A summer intern here wrote a file system called "urlfs".
Basically a "clone" style interface for fetching web pages,
which decouples the transport from the browser.

I've been cleaning it up in an idle thread.  I renamed it
webfs, made it work with the new 9p library, and started
to add plumbing support before I got thoroughly disgusted
with the code.  A rewrite is required.

In the future, URLs will be plumbed to webfs.  Webfs will
start fetching the URL, determine the Mime type, and
send a new plumb message with a path name under
/mnt/web as the data, and the Mime type as an attribute.
The plumbing rules will then determine the correct
destination (eg Charon, page, acme, ...) from the Mime
type (with file suffix as fallback).

This will be a vast improvement over the existing model,
which erroneously assumes that all http:// urls should be
handled by an html browser...

Frame subsidiaries with be handled by Charon (or i)
through the existing clone interface.

Re: [9fans] vfork and paging

[forsyth]

>> > There are (at least) two libraries providing CSP-style channels for Java:
>> >
>> >   http://www.cs.ukc.ac.uk/projects/ofa/jcsp
>> >   http://www.rt.el.utwente.nl/javapp/
>> 
>> and they both (well, especially jcsp) look substantially more complex
>> (and awkward) than the plan 9 threads library, let alone Limbo...

they certainly don't suffer from failure of schism

Re: [9fans] vfork and paging

[rog]

> There are (at least) two libraries providing CSP-style channels for Java:
>
>   http://www.cs.ukc.ac.uk/projects/ofa/jcsp
>   http://www.rt.el.utwente.nl/javapp/

and they both (well, especially jcsp) look substantially more complex
(and awkward) than the plan 9 threads library, let alone Limbo...

i took a simple example from CTJ and wondered what it looked like
under the various systems:

Limbo:
	for (i := 0; i < 20; i++) {
		alt {
		n := <-inChannel[0] =>
			... do something with n
		n := <-inChannel[1] =>
			... do something with n
		}
	}

Plan 9:
	int i, n;
	Alt alts[3];
	alts[0].c = inChannel[0];
	alts[0].v = &n;
	alts[0].op = CHANRCV;
	alts[1].c = inChannel[1];
	alts[1].v = &n;
	alts[1].op = CHANRCV;
	alts[2].op = CHANEND;

	for (i = 0; i < 20; i++) {
		switch(alt(alts)) {
		case 0:
			... do something with n
			break;
		case 1:
			... do something with n
			break;
		}
	}

CTJ:
	Integer n = new Integer(); // n is an Object
	Process alt = new Alternative(new Guard[] {
		new Guard(inChannel[0], new Process() {
			public void run() {
				inChannel[0].read(n);
				... do something with n
			}
		}),
		new Guard(inChannel[1], new Process() {
			public void run() {
				inChannel[1].read(n);
				... do something with n
			}
		})
	};
	for (int i=0; i<20; i++) {
		alt.run();
	}


JCSP:
	i couldn't quickly work out how to do it with jcsp.
	it has about 40 classes just for the basic primitives...
	the plan 9 thread library has 38 functions *in total*.

basically, when it comes down to it, there's no substitute for decent
language-level primitives.  though it's nice to see there are others
around that acknowledge the inadequacies of the conventional
schemes...

  rog.

Re: [9fans] vfork and paging

[Richard Miller]

forsyth@vitanuova.com says (and I agree) -

> ... Communicating Sequential Processes
> encourages the composition of sequential processes to solve
> concurrent problems.   in its <thread.h> or Newsqueak/Alef/Limbo
> guises which all allow sending channels down channels, you can
> go a bit further.  unfortunately, many `threads' designs tend by
> contrast to be stuck in the lock/sleep/wakeup model of the late 1960s.
> that java stuff is a nightmare.

There are (at least) two libraries providing CSP-style channels for Java:

  http://www.cs.ukc.ac.uk/projects/ofa/jcsp
  http://www.rt.el.utwente.nl/javapp/

See the mailing list java-threads@ukc.ac.uk for current research activity in
this area.

-- Richard

Re: [9fans] vfork and paging

[Ronald G Minnich]

On Wed, 3 Oct 2001, Borja Marcos wrote:

> 	Curiously, very few people write concurrent programs. Multitasking operating
> systems are used as multiprogramming systems to run more than one program,
> but most of those programs are sequential.

that's cause most people can't do it well. SPMD is about as good as people
can mostly think about. Anything harder usually gets screwed up. I don't
know why.

> 	Is it a lost art? ;-)

did anybody ever find it?

ron

Re: [9fans] vfork and paging

[Borja Marcos]

On Wednesday 03 October 2001 11:49, you wrote:
> writing correct programs is hard, but the addition of concurrency
> need not make it harder, and indeed if the problem
> includes concurrency (as with networks, file servers and interaction),
> having concurrency in the system and language can make it
> much easier to get it right, with structurally simpler solutions,
> compared to (say) the event driven schemes.

	Concurrency demands a strong design, but that can give you a much simpler to 
understand program, and much easier to maintain. However, you need to be 
careful.

	Curiously, very few people write concurrent programs. Multitasking operating 
systems are used as multiprogramming systems to run more than one program, 
but most of those programs are sequential.

	Is it a lost art? ;-)


	Borja.

Re: [9fans] vfork and paging

[Boyd Roberts]

> writing correct programs is hard, but the addition of concurrency
> need not make it harder, ...

perhaps, but it really does depend on the underlying environment.
windoze is a prime example.  that horrible, event driven, ghastly
mess makes it near impossible to write a program that even works.

take winsock -- the messages arrive in a random order;  i've seen
'write true' turn up before 'connected'.  yup, add another case
into the switch.  and the idiots write stuff that exploit weird
junk like do an async connect and then wait/loop for 'write true'
in braindamaged ways.

Re: [9fans] vfork and paging

[Boyd Roberts]

From: <rog@vitanuova.com>
> > there's a thread lib for plan 9?
> 
> there is (see thread(2)).

cool.  ta.
 
> thread (i.e.  shared memory multiprocess) programming isn't too hard
> if you have a decent IPC model.

err, bugs, dumping core, 'broken' is one thing.

you mess that up in the kernel and the consequences can
'ruin your whole day' (tm).

Re: [9fans] vfork and paging

[rog]

> there's a thread lib for plan 9?

there is (see thread(2)).

thread (i.e.  shared memory multiprocess) programming isn't too hard
if you have a decent IPC model.  alef, plan 9's libthread, and Limbo
all use essentially the same model, synchronous channel communication,
based on Hoare's CSP.

language support eases the difficulties substantially: the by-value
lists, strings and tuples in Limbo make it easier to concentrate on
the difficult bits while being assured that your data isn't being
corrupted due to an oversight.

  rog.

Re: [9fans] vfork and paging

[forsyth]

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

writing correct programs is hard, but the addition of concurrency
need not make it harder, and indeed if the problem
includes concurrency (as with networks, file servers and interaction),
having concurrency in the system and language can make it
much easier to get it right, with structurally simpler solutions,
compared to (say) the event driven schemes.

of course, it depends on the approach taken to concurrency.
there are several appealing models, but CSP's processes and channels
model works well.  Communicating Sequential Processes
encourages the composition of sequential processes to solve
concurrent problems.   in its <thread.h> or Newsqueak/Alef/Limbo
guises which all allow sending channels down channels, you can
go a bit further.  unfortunately, many `threads' designs tend by
contrast to be stuck in the lock/sleep/wakeup model of the late 1960s.
that java stuff is a nightmare.


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

To: <9fans@cse.psu.edu>
Subject: Re: [9fans] vfork and paging
Date: Wed, 3 Oct 2001 09:38:08 +0200
Message-ID: <058701c14bde$5b014f80$a2b9c6d4@SOMA>

> if i ever have to do multi-threaded code in C on another platform
> again i shall port and use the plan 9 thread library - it's by far the
> most reasonable i've seen.

there's a thread lib for plan 9?

i believe that threads were outlawed, because thread programming was
considered to be too hard.  which isn't a bad thing 'cos writing
correct programs is hard enough and the closest you used to get to
threads was kernel hacking and that code/compile/run cycle is damn
painful.

at least threads are in user mode so your m/c doesn't crash and
your f/s doesn't get trashed.

Re: [9fans] vfork and paging

[Boyd Roberts]

> if i ever have to do multi-threaded code in C on another platform
> again i shall port and use the plan 9 thread library - it's by far the
> most reasonable i've seen.

there's a thread lib for plan 9?

i believe that threads were outlawed, because thread programming was
considered to be too hard.  which isn't a bad thing 'cos writing
correct programs is hard enough and the closest you used to get to
threads was kernel hacking and that code/compile/run cycle is damn
painful.

at least threads are in user mode so your m/c doesn't crash and
your f/s doesn't get trashed.

Re: [9fans] vfork and paging

[forsyth]

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

that restriction should go from Limbo fairly soon as well.
it's unmodular.


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

From: "rob pike" <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] vfork and paging
Date: Tue, 2 Oct 2001 15:25:07 -0400
Message-ID: <20011002192514.A243119A5F@mail.cse.psu.edu>

> the difficult part is flushing, of course.

Not any more.  Alef had a restriction that a channel couldn't
be involved in two alts at once.  The thread library has no
such restriction and flushing is now easy.

-rob

Re: [9fans] vfork and paging

[rob pike]

> the difficult part is flushing, of course.

Not any more.  Alef had a restriction that a channel couldn't
be involved in two alts at once.  The thread library has no
such restriction and flushing is now easy.

-rob

Re: [9fans] vfork and paging

[rog]

> I think the way acme (and later rio) manages the resources for the client
> connections - the Xfid data type and control described in the acme paper
> - is one of the best ideas I ever had.  Dynamic channels roll!

the difficult part is flushing, of course.

i've had happy experiences using procs and channels for managing
animations in a card game program where any number of cards can be
flying around the place concurrently in response to network events,
the user continues to interact at the same time, and the internal
database must be kept consistent.

it uses processes in a way that in other systems would be considered
profligate (one process for each animation plus one for each
destination) but performance is just fine, even on slower processors
(e.g.  on the ipaq).

and whereas such a system built in a conventional style would probably
be highly fragile and involve some quite difficult state transitions,
this is robust and it would be trivial to add some more interesting
kinds of animations (e.g.  dice rolling) without impacting the
complexity of any of the rest of the system.

in fact, i *tried* to implement such a system on another system
(NeXTstep) and failed; too much complexity all at once.

  rog.

Re: [9fans] vfork and paging

[Russ Cox]

> I would say that most of the programs written in our group here that
> require any level of concurrency (most of those implement file systems
> or deal with a graphical interface) use the thread library.  Here are some
> of them:
> 
> archfs, nntpfs, ramfs, acme, apm, consolefs, depend, olefs,
> bitsy/keyboard, bitsy/prompter, cdfs, plumber.c, rio, samterm, snapfs,
> usbaudio, usbmouse, usbd, webfs, wikifs, flashfs

This is misleading.  Many of these use the thread library
only for the Ref counters, and only because they use lib9p.
They're not actually threaded in the sense of having
a threadmain, channels, and so on.  The filtered list is:

acme, apm, consolefs, depend, bitsy/keyboard, bitsy/prompter,
plumber, rio, samterm, usbaudio, usbmouse, usbd, webfs

The general sentiment still holds true, though: rio and
acme are heavily threaded, and the others are moderately
threaded, mainly based on their level of concurrency.

If only the rest of the world would accept that thread
or process doesn't have to mean slow.

Russ

Re: [9fans] vfork and paging

[rob pike]

> the
> possibilities afforded by dynamic channels are wonderful...; they make
> some things so simple to implement.

I think the way acme (and later rio) manages the resources for the client
connections - the Xfid data type and control described in the acme paper
- is one of the best ideas I ever had.  Dynamic channels roll!

-rob

Re: [9fans] vfork and paging

[rog]

> It is indeed true that you have to know what your program does.  With
> the thread library by default you share memory and fd's so accessibility
> doesn't change twixt light and heavy threads, though syncronization problems
> will be more likely to rear their ugly heads in the latter.

i was finding it difficult to debug rio, possibly because it has a
good mix of procs and threads and working out which function is being
called from what isn't too easy...

> I wrote ndb/cs and ndb/dns before the thread library and it was a bit
> of a pain.  I'le like to redo dns with it.

if i ever have to do multi-threaded code in C on another platform
again i shall port and use the plan 9 thread library - it's by far the
most reasonable i've seen.

i would miss the type checking on channels though.

i used to use occam, which had channels, but you could only use them
completely statically (no dynamic memory, no recursion, etc); the
possibilities afforded by dynamic channels are wonderful...; they make
some things so simple to implement.

  rog.

Re: [9fans] vfork and paging

[Fco.J.Ballesteros]

:  usbaudio, usbmouse, usbd, webfs, wikifs, flashfs

webfs? 

Is it that there's now some fs to browse the web? 
Or am I dreaming?

Re: [9fans] vfork and paging

[Sape Mullender]

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

You're not dreaming, but webfs is not what you might call functional
yet.  It's unclear whether it'll ever be.  I don't know who uses it here.

	Sape


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

From: Fco.J.Ballesteros <nemo@gsyc.escet.urjc.es>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] vfork and paging
Date: Tue, 2 Oct 2001 16:27:09 +0100
Message-ID: <20011002142501.C17AF199F3@mail.cse.psu.edu>

:  usbaudio, usbmouse, usbd, webfs, wikifs, flashfs

webfs? 

Is it that there's now some fs to browse the web? 
Or am I dreaming?

Re: [9fans] vfork and paging

[rog]

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

the down side of this is that when debugging or inspecting the code,
it's not immediately obvious whether a given function is running as a
proc or a thread; e.g.  where shared access to a data structure might
be a problem, or where a system call is intended to block all other
threads.

  rog.


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


-rob

Re: [9fans] vfork and paging

[presotto]

> the down side of this is that when debugging or inspecting the code,
> it's not immediately obvious whether a given function is running as a
> proc or a thread; e.g.  where shared access to a data structure might
> be a problem, or where a system call is intended to block all other
> threads.

It is indeed true that you have to know what your program does.  With
the thread library by default you share memory and fd's so accessibility
doesn't change twixt light and heavy threads, though syncronization problems
will be more likely to rear their ugly heads in the latter.

Blocking is a problem.  There's no particular reason to know whether a
thread will block or not if it calls a library routine that you didn't
write.  I haven't found it a problem, but that's largely because our
libraries are pretty simplistic so that I can guess if they would block
or not.

I wrote ndb/cs and ndb/dns before the thread library and it was a bit
of a pain.  I'le like to redo dns with it.

Re: [9fans] vfork and paging

[rog]

> I always thought this made sense too. I always wondered though why Alef
> had threads. And who's using the thread library?

that's a good point.

even when OS processes are cheap, they're still not as cheap as
longjmp()...  hence the thread library, presumably.

it's interesting to see that despite the distinction between threads
and procs in the thread library, the API is the same - the same
communication and synchronisation primitives work between all of them.

internally, Inferno also has the same distinction between threads and
processes ("progs and kprocs"), although the distinction isn't visible
at the API level.  simple threads are used until a call is encountered
that may block on an external event, in which case a kproc is summoned
for the operation.

a channel communication doesn't count as an external event, so one can
write quite sophisticated multi-process programs quite cheaply.
(it's a bit more awkward & error prone in C than in Limbo though
as it doesn't have the language support)

  rog.

Re: [9fans] vfork and paging

[Sape Mullender]

rminnich@lanl.gov (ron):
>  And who's using the thread library?

I would say that most of the programs written in our group here that
require any level of concurrency (most of those implement file systems
or deal with a graphical interface) use the thread library.  Here are some
of them:

archfs, nntpfs, ramfs, acme, apm, consolefs, depend, olefs,
bitsy/keyboard, bitsy/prompter, cdfs, plumber.c, rio, samterm, snapfs,
usbaudio, usbmouse, usbd, webfs, wikifs, flashfs

Re: [9fans] vfork and paging

[rob pike]

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

The acme paper talks about this a little.  Our threads are really just
user-level coroutines.  Their utility is that schedulding is easy to
understand: thread switching will occur only at communication points.
This means that no interlocking of data structures is required between
threads in the same process, and it's easy to write applications (like
acme) that use processes to gather I/O and send the data to a single
central process composed of lots of threads.  The total amount of
locking, and potential for concurrency bugs, is greatly reduced.

-rob


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

From: Ronald G Minnich <rminnich@lanl.gov>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] vfork and paging
Date: Tue, 2 Oct 2001 07:34:06 -0600 (MDT)
Message-ID: <Pine.LNX.4.33.0110020732590.26669-100000@snaresland.acl.lanl.gov>

On Tue, 2 Oct 2001, Boyd Roberts wrote:

> > Our approach was different, as Plan 9 users will appreciate.
> > Processes, rather than being a scourge to be avoided or
> > perhaps hidden behind an advertising adjective, are the
> > solution to many a systems problem and should be embraced.
>
> couldn't agree more.

I always thought this made sense too. I always wondered though why Alef
had threads. And who's using the thread library?

ron

Re: [9fans] vfork and paging

[Sape Mullender]

rminnich@lanl.gov (ron):
>  And who's using the thread library?

I would say that most of the programs written in our group here that
require any level of concurrency (most of those implement file systems
or deal with a graphical interface) use the thread library.

Re: [9fans] vfork and paging

[Ronald G Minnich]

On Tue, 2 Oct 2001, Boyd Roberts wrote:

> > Our approach was different, as Plan 9 users will appreciate.
> > Processes, rather than being a scourge to be avoided or
> > perhaps hidden behind an advertising adjective, are the
> > solution to many a systems problem and should be embraced.
>
> couldn't agree more.

I always thought this made sense too. I always wondered though why Alef
had threads. And who's using the thread library?

ron

Re: [9fans] vfork and paging

[Boyd Roberts]

> Our approach was different, as Plan 9 users will appreciate.
> Processes, rather than being a scourge to be avoided or
> perhaps hidden behind an advertising adjective, are the
> solution to many a systems problem and should be embraced.

couldn't agree more.

Re: [9fans] vfork and paging

[forsyth]

>> the BSD approach is poor.  unfortunately, people mimic it.
>> i can only assume that one or more textbooks wrote it up.

> Our approach was different, as Plan 9 users will appreciate.
> Processes, rather than being a scourge to be avoided or
> perhaps hidden behind an advertising adjective, are the
> solution to many a systems problem and should be embraced.

i was referring to the paging implementation but it's true of
the approach to processes too.

Re: [9fans] vfork and paging

[rob pike]

> the BSD approach is poor.  unfortunately, people mimic it.
> i can only assume that one or more textbooks wrote it up.

At the time, people confused the whole idea of processes with
the Unix implementation.  The result was a deep-seated belief,
still rampant in the minds of the impressionable and the rigid,
that processes are inherently expensive.   Lightweight process
and threads grew out of that misconception.  One of the very
first things I measured when the early Plan 9 kernel was running
- and those who know me know I'm not a big measurement
nut - was the time it took to create a new process, so I could
demonstrate to anyone who would listen (there were only a
few) that processes were not inherently expensive.

Our approach was different, as Plan 9 users will appreciate.
Processes, rather than being a scourge to be avoided or
perhaps hidden behind an advertising adjective, are the
solution to many a systems problem and should be embraced.

-rob

Re: [9fans] vfork and paging

[Boyd Roberts]

> the bits required aren't there in the hardware page tables, but you
> can either emulate them or do copy on reference.

yes, truly ugly.

Re: [9fans] vfork and paging

[forsyth]

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

the bits required aren't there in the hardware page tables, but you
can either emulate them or do copy on reference.  if you use a paging
algorithm with local policy instead of the global one used by
berkeley, you can also prevent some pathetic effects under load, and
remove complex data structures and code (or not require them in the
first place).  this was well studied during the late 1960s and early
1970s.  the BSD approach is poor.  unfortunately, people mimic it.
i can only assume that one or more textbooks wrote it up.


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] authorization schemes (was CORBA)
Date: Mon, 1 Oct 2001 09:49:55 GMT
Message-ID: <3BB3722D.2D77B4BE@null.net>

Boyd Roberts wrote:
> vfork()?  was the v for vomit?

According to some of the Berkeleyites, there was a flaw in
the VAX-11/750 memory management unit (microcode?) such
that they were unable to use copy-on-write.  When I
mentioned this to the AT&T UNIX System V developers, they
said it seemed to work fine for them..