libkse observations [Was: Re: libthr broken]

[Daniel Eischen]

On Thu, 1 May 2003, Vallo Kallaste wrote:

> On Wed, Apr 30, 2003 at 11:25:04AM -0400, Daniel Eischen
> <eischen at pcnet1.pcnet.com> wrote:
> 
> > I just committed a fix for this.  I can now run knode, although I
> > get:
> > 
> > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
> > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
> > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
> > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
> > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
> > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
> > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action.
> > 
> > I am running kde3.1 but built with X 4.2.99 from the XFree86 CVS tree (not
> > via the port), so that may have something to do with it.
> 
> The kdecore messages are harmless and present even with libc_r.
> Now KNode starts up and is useable as before and the same bugs as
> before remain. I have configured KNode to start up external editor
> (gvim), which it does. After editing and :wq KNode still thinks that
> external editor is running while it's long gone. The text from the
> temporary file (/tmp/kde-vallo/knode?????) will not be transferred
> to KNode's native text editor window. Closing KNode gets rid of the
> KNode UI, but it remains running accordingly to ps and top. It has
> no state per top and is killable via TERM.

I think there is something wrong with SIGCHLD not getting
properly sent/received to libkse processes, or perhaps
libkse just doesn't dispatch the signal correctly.

> Mozilla still will not start up. It's present in the process table
> but no UI will show up. Top will show mozilla process steadily in
> the RUN state, using zero CPU and it's not killable via TERM.

This is a bug in rtld-elf as discussed earlier on this
list (threads@).  It isn't thread-safe and the tricks it
uses to prevent thread swap-out work for libc_r, but not
for libkse.  This problem was just added to the TODO list
for 5.1-release.

Here's a hack to libpthread to temporarily get around this
problem, though it might cause other problems (allowing
CPU hungry threads to starve other threads).

-- 
Dan Eischen

Index: thread/thr_kern.c
===================================================================
RCS file: /home/ncvs/src/lib/libpthread/thread/thr_kern.c,v
retrieving revision 1.62
diff -u -r1.62 thr_kern.c
--- thread/thr_kern.c	30 Apr 2003 15:05:17 -0000	1.62
+++ thread/thr_kern.c	1 May 2003 20:19:02 -0000
@@ -784,7 +784,8 @@
 	if (curthread == NULL)
 		;  /* Nothing to do here. */
 	else if ((curthread->need_switchout == 0) &&
-	    (curthread->blocked == 0) && (THR_IN_CRITICAL(curthread))) {
+	    (curthread->blocked == 0) &&
+	    ((THR_IN_CRITICAL(curthread)) || (curthread->state == PS_RUNNING))) {
 		/*
 		 * Resume the thread and tell it to yield when
 		 * it leaves the critical region.