Commit Graph

18 Commits

Author SHA1 Message Date
David Xu
1279572a92 s/SGNL/SIG/
s/SNGL/SINGLE/
s/SNGLE/SINGLE/

Fix abbreviation for P_STOPPED_* etc flags, in original code they were
inconsistent and difficult to distinguish between them.

Approved by: julian (mentor)
2002-09-05 07:30:18 +00:00
David Xu
35c32a76f9 In the kernel code, we have the tsleep() call with the PCATCH argument.
PCATCH means 'if we get a signal, interrupt me!" and tsleep returns
either EINTR or ERESTART depending on the circumstances.  ERESTART is
"special" because it causes the system call to fail, but right as it
returns back to userland it tells the trap handler to move %eip back a
bit so that userland will immediately re-run the syscall.
This is a syscall restart. It only works for things like read() etc where
nothing has changed yet. Note that *userland* is tricked into restarting
the syscall by the kernel. The kernel doesn't actually do the restart. It
is deadly for things like select, poll, nanosleep etc where it might cause
the elapsed time to be reset and start again from scratch.  So those
syscalls do this to prevent userland rerunning the syscall:
  if (error == ERESTART) error = EINTR;

Fake "signals" like SIGTSTP from ^Z etc do not normally invoke userland
signal handlers. But, in -current, the PCATCH *is* being triggered and
tsleep is returning ERESTART, and the syscall is aborted even though no
userland signal handler was run.
That is the fault here.  We're triggering the PCATCH in cases that we
shouldn't.  ie: it is being triggered on *any* signal processing, rather
than the case where the signal is posted to userland.
	--- Peter

The work of psignal() is a patchwork of special case required by the process
debugging and job-control facilities...
	--- Kirk McKusick
	"The design and impelementation of the 4.4BSD Operating system"
	Page 105

in STABLE source, when psignal is posting a STOP signal to sleeping
process and the signal action of the process is SIG_DFL, system will
directly change the process state from SSLEEP to SSTOP, and when
SIGCONT is posted to the stopped process, if it finds that the process
is still on sleep queue, the process state will be restored to SSLEEP,
and won't wakeup the process.

this commit mimics the behaviour in STABLE source tree.

Reviewed by: Jon Mini, Tim Robbins, Peter Wemm
Approved by: julian@freebsd.org (mentor)
2002-09-03 12:56:01 +00:00
Julian Elischer
88151aa3f5 Fix crack-smoking code that was panicing on the quad xeon:
- If either of proc or kse are NULL during thread_exit(), then
          the kernel is going to fault because parts of the function
          assume they aren't NULL.  Instead, just assert they aren't NULL
          (as well as the kse group) and assume they are in all of the
          code.  It doesn't make sense for them to be NULL here anyways.
        - Move the PROC_UNLOCK(p) up above clearing td_proc, etc. since
          otherwise we will panic if the proc's lock is contested.

Submitted by:	jhb@freebsd.org
2002-08-29 19:49:53 +00:00
Julian Elischer
49539972e9 slight cleanup of single-threading code for KSE processes 2002-08-22 21:45:58 +00:00
Julian Elischer
721e591067 Revert some suspension/sleep/signal code from KSE-III
We need to rethink a bit of this and it doesn't matter if
we break the KSE test program for now as long
as non-KSE programs act as expected.

Submitted by:	David Xu <bsddiy@yahoo.com>
	(this guy's just asking to get hit with a commit bit..)
2002-08-21 20:03:55 +00:00
Julian Elischer
67759b33f6 Fix a comment. 2002-08-01 19:10:40 +00:00
Julian Elischer
8625e3721f get suspension counting right.
fix an error message

Submitted by:	David Xu <bsddiy@yahoo.com>
2002-07-25 03:21:35 +00:00
Julian Elischer
e3b9bf7198 fix some style problems and remove a mis-merged assert. 2002-07-25 00:27:39 +00:00
Julian Elischer
b6d5995e5f Add some locking asserts and some comments 2002-07-24 23:21:05 +00:00
Julian Elischer
cf19bf911d When single threading a multithreaded program, awaken the
'single threading thread' when the last other thread suspends.
I had this code in there before but it seems to have been
accidentally deleted somewhere along the way.  This would only affect
multithreaded processes.

Reviewed by:	David Xu <bsddiy@yahoo.com>
2002-07-24 19:50:08 +00:00
Julian Elischer
205683663f When suspending a thread, update the appropriate (sic) statistic. 2002-07-24 07:29:16 +00:00
Peter Wemm
02fb42b0a8 ia64 does not have the same degree of stealth include file nesting,
so it needs an explicit #include <machine/frame.h> to get 'struct
trapframe'.  The fact that it needs this at this level is rather bogus
but it will not compile without it.
2002-07-17 23:43:55 +00:00
Peter Wemm
8a2bd34560 Pacify gcc on ia64 2002-07-17 23:32:13 +00:00
Julian Elischer
c3b98db091 Thinking about it I came to the conclusion that the KSE states were incorrectly
formulated.  The correct states should be:
IDLE:  On the idle KSE list for that KSEG
RUNQ:  Linked onto the system run queue.
THREAD: Attached to a thread and slaved to whatever state the thread is in.

This means that most places where we were adjusting kse state can go away
as it is just moving around because the thread is..
The only places we need to adjust the KSE state is in transition to and from
the idle and run queues.

Reviewed by:	jhb@freebsd.org
2002-07-14 03:43:33 +00:00
Peter Wemm
a136efe9b6 Collect all the (now equivalent) pmap_new_proc/pmap_dispose_proc/
pmap_swapin_proc/pmap_swapout_proc functions from the MD pmap code
and use a single equivalent MI version.  There are other cleanups
needed still.

While here, use the UMA zone hooks to keep a cache of preinitialized
proc structures handy, just like the thread system does.  This eliminates
one dependency on 'struct proc' being persistent even after being freed.
There are some comments about things that can be factored out into
ctor/dtor functions if it is worth it.  For now they are mostly just
doing statistics to get a feel of how it is working.
2002-07-07 23:05:27 +00:00
Peter Wemm
b799f5a475 Make this compile on 64 bit platforms 2002-07-07 22:27:40 +00:00
Andrew R. Reiter
c0854cd341 - In thread_userret(), remove the Giant locking and unlocking around the
call to thread_alloc().

Approved by:	julian
Reviewed by:	jake, jeff
2002-07-01 03:15:16 +00:00
Julian Elischer
44990b8cb8 Add files that are new for KSE. 2002-06-29 07:04:59 +00:00