See for pointers to diffs
or other ways of getting the sources..

At this stage it is as good as I can get it right now.
It builds world. It runs teh sampel threaded program, it even does both
at the same time.. 
Matt has run it on an SMP machine and there are patches for various
architectures (stubbed) to allow them to keep working
(as long as they don't try threading :-).

I would like to commit this as soon as I have feedback from the usual

I do have the following issues on my list but I'd like ot commit BEFORE
fixing them:

1/ psignal has been rewritten, but needs to be re-re-written. It works but
I'd like any signal gurus to feel free to hack at it after it's committed.

2/ Ptrace works but once again, Anyone whoe knows and loves ptrace could
probably do with rewriting parts of it in teh light of threads once it is
committed. (I can gdb normal programs but threaded programs are not likely
to cooperate.

3/ I have some cleanups to do in the generation of upcalls. there is still
un-needed information being stored for theupcall and it can probably be

4/ The definition of a 'suspended' process has been changed. It should be
changed again. I have some code to keep a track of which threads are
currently in userland and which are in the kernel, with a counter in teh
process so you can instantly tell how many threads are where. This will
sim-lify some of the suspend code.

5/ Matt and I decided that we need to change the behaviour of 'BOUND'
threads in a KSE process so that their KSEs can be lent to other threads
in the same group that need to complete kernel operations.. BOUND threads
are those that for some reason are not operating in threaded mode (e.g.
they were in the UTS or some other critical code). The change is that
BOUND threads can lend out their KSEs (scheduler spots) to other threads
as long as those threads do not return to user land. (At least not on that

6/ code cleanup in the code that aborts sleeps and condvar waits.

There are also a lot of debugging aids that I will delete BEFORE
checkin. Please ignore them when reviewing. (e.g. KASSERTS in

IN ADDITION TO THIS, (damned caps lock) there are still code paths that
can not possibly succeed in a multi threaded world. What milestone 3 gives
is enough of the most common codepaths cleaned up so that a very simple
threaded program can run, be suspended, restarted and exit.

There is still no ability to run threads on multiple processors as there
is still only one KSE (schedulable entity) per process.

Having said all this I think it is ready to commit.

I will try respond to immidiate concerns people have but 
since we will have a working system after the commit,
I'd like to do as much stuff after the commit as possible to allow others
to test and comment.  Next week I will have to spend a lot of time on work
matters so I'd like to get this in in 24 hours from now, and have the
weekend to  handle problems that arrise.

Estimated commit time: (assuming current works at that time)
will be around 1AM GMT June 29
that will be 6PM here in San Francisco.


p.s. I will put the test programs in the tools tree soemwhere..

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to