Date: Thu, 1 May 2003 16:20:56 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Vallo Kallaste <kalts@estpak.ee> Cc: Julian Elischer <julian@elischer.org> Subject: Re: libkse observations [Was: Re: libthr broken] Message-ID: <Pine.GSO.4.10.10305011613410.27961-100000@pcnet1.pcnet.com> In-Reply-To: <20030501200911.GA721@kevad.internal>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 1 May 2003, Vallo Kallaste wrote:
> On Wed, Apr 30, 2003 at 11:25:04AM -0400, Daniel Eischen
> <eischen@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10305011613410.27961-100000>