Re: cvs commit: src/sys/fs/procfs procfs.c procfs.h ...
Jun Kuriyama [EMAIL PROTECTED] writes: On my environment, I cannot build GENERIC kernel after this. Umm, sorry, I forgot the other HEADS UP: PROCFS requires PSEUDOFS. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
weird NTFS and FTPD performance
I reinstalled my laptop with quite current current (20011126-JPSNAP) because I need to access NTFS partition and have 32bit PCCARD NIC (NTFS was just unbroken on current AFAIK). When I connect with ftp to 4.3-RELEASE using 100Mbps-FDX I can upload from NTFS partition with about 6MB/s (limited by disk - in systat I see lots of 4KB requests, disk usage about 90%). When connecting from 4.3 to FTPD running on current I get 7MB downloading from UFS slice and 1MB for NTFS partition! Systat show lots of 244KB requests (totalling in 22MB/s - nonsense on this disk). I expect the problem is in NTFS but there must be something important in a way ftpd reads files to serve. I can give you all the info you would need. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: parallel port i/o hogs cpu badly; is this normal?
On Sun, Dec 02, 2001 at 02:10:58PM -0500, Kenneth Culver wrote: I don't know if there's a way to stop this, but it's normal, whenever I use my Parallel port zip drive, I have similar problems. For extended mode, currently FIFO+DMA, you may try : lptcontrol -e By this is experimental. It worked on my own config, but nobody else tried it, even me since a long time. Otherwise, you have lptcontrol -i but this should be the default already. -- Alcôve Technical Manager - [EMAIL PROTECTED] - http://www.alcove.com FreeBSD Developer - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: truss(1) out of commission
On 4 Dec 2001, Dag-Erling Smorgrav wrote: Bruce Evans [EMAIL PROTECTED] writes: Please only commit working code. Tell that to the author of truss(1) (who also wrote procfs(5) in the first place). It used to work. Did it not work when it was first committed? Anyway, there are many more developers now, so breaking the build or a utility wastes more peoples time. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: truss(1) out of commission
* Bruce Evans [EMAIL PROTECTED] [011204 13:43] wrote: On 4 Dec 2001, Dag-Erling Smorgrav wrote: Bruce Evans [EMAIL PROTECTED] writes: Please only commit working code. Tell that to the author of truss(1) (who also wrote procfs(5) in the first place). It used to work. Did it not work when it was first committed? Anyway, there are many more developers now, so breaking the build or a utility wastes more peoples time. I think what DES is aptly saying is that although it worked, the way in which it worked has caused us a lot problems and it deserves a good replacement. Let me also state in the author's defense (Sean i think) that it's much easier to rewrite something that has already been written than to be the initial implementor and even though it looks like it's in for a rewrite one must congratulate him on a job that has lasted us so long. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP ATA support for newer SiS chipsets added
--On Monday, December 03, 2001 11:10:47 +0100 SXren Schmidt [EMAIL PROTECTED] wrote: It seems Miklos Niedermayer wrote: I think they are idle (looking at vmstat -i), but i can't be sure. However i have 2 machines here with VIA 82C596 chipset... atapci0: VIA 82C596 ATA66 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ad0: 28629MB QUANTUM FIREBALLlct20 30 [58168/16/63] at ata0-master UDMA66 524288 bytes transferred in 0.025247 secs (20766367 bytes/sec) It's idle (the LED isn't blinking after/before dd and vmstat -i doesn't show any ata0 activity). Even my Intel PIIX4 ATA33 controller with the same disk performs better (a little)... Hmm, yes that looks somewhat on the low side... Well, two things, the older VIA chips are not the best performers, but I still think it should be better than that, I'll run some tests here, I might have messed up something... Are we talking -current or -stable here ? I'm getting even worse performance. root@lobster# for n in 1 2 3 4 5 do dd if=/dev/ad0 of=/dev/null bs=512k count=1 done 1+0 records in 1+0 records out 524288 bytes transferred in 0.056385 secs (9298353 bytes/sec) 1+0 records in 1+0 records out 524288 bytes transferred in 0.062027 secs (8452580 bytes/sec) 1+0 records in 1+0 records out 524288 bytes transferred in 0.056339 secs (9305947 bytes/sec) 1+0 records in 1+0 records out 524288 bytes transferred in 0.056325 secs (9308271 bytes/sec) 1+0 records in 1+0 records out 524288 bytes transferred in 0.056482 secs (9282398 bytes/sec) root@lobster# atapci0: Intel ICH2 ATA100 controller port 0xb800-0xb80f at device 31.1 on pci0 ad0: 58644MB IBM-DTLA-307060 [119150/16/63] at ata0-master tagged UDMA100 Paul Richards FreeBSD Services Ltd http://www.freebsd-services.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADSUP!! kernel burncd must be in sync again.
I've just added VCD/SVCD support and that needs the kernel and burncd to be in sync. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make release breakage: src/sbin/ifconfig
With 5-current as of Dec/04/2001 15:00:00 GMT. It seems that this is because 'WARNS=0' line is inside of !defined(RELEASE_CRUNCH) clause. IMO, if an application's code requires to set 'WARNS=0 for build, it should also be set when building as a part of a crunched binary. -- - Makoto `MAR' Matsushita (cd /usr/src/sbin/ifconfig make -DRELEASE_CRUNCH -Dlint depend make -DRELEASE_CRUNCH -Dlint ifconfig.o ifmedia.o ifieee80211.o) rm -f .depend mkdep -f .depend -a-DUSE_IF_MEDIA -DUSE_IEEE80211 -DNO_IPX -DNS -I.. /usr/src/sbin/ifconfig/ifconfig.c /usr/src/sbin/ifconfig/ifmedia.c /usr/src/sbin/ifconfig/ifieee80211.c cd /usr/src/sbin/ifconfig; make _EXTRADEPEND echo ifconfig: /usr/lib/libc.a .depend cc -O -pipe -DUSE_IF_MEDIA -DUSE_IEEE80211 -DNO_IPX -DNS -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -I.. -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -c /usr/src/sbin/ifconfig/ifconfig.c cc1: warnings being treated as errors /usr/src/sbin/ifconfig/ifconfig.c:157: warning: declaration of `name' shadows global declaration /usr/src/sbin/ifconfig/ifconfig.c:197: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:197: warning: (near initialization for `cmds[0].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:198: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:198: warning: (near initialization for `cmds[1].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:199: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:199: warning: (near initialization for `cmds[2].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:200: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:200: warning: (near initialization for `cmds[3].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:201: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:201: warning: (near initialization for `cmds[4].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:202: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:202: warning: (near initialization for `cmds[5].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:203: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:203: warning: (near initialization for `cmds[6].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:204: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:204: warning: (near initialization for `cmds[7].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:205: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:205: warning: (near initialization for `cmds[8].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:206: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:206: warning: (near initialization for `cmds[9].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:207: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:207: warning: (near initialization for `cmds[10].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:213: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:213: warning: (near initialization for `cmds[11].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:226: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:226: warning: (near initialization for `cmds[12].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:227: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:227: warning: (near initialization for `cmds[13].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:228: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:228: warning: (near initialization for `cmds[14].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:229: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:229: warning: (near initialization for `cmds[15].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:230: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:230: warning: (near initialization for `cmds[16].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:232: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:232: warning: (near initialization for `cmds[18].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:233: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:233: warning: (near initialization for `cmds[19].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:234: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:234: warning: (near initialization for `cmds[20].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:235: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:235: warning: (near initialization for `cmds[21].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:236: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:236: warning: (near initialization for `cmds[22].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:237: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:237: warning: (near initialization for `cmds[23].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:238: warning: missing initializer
Re: make release breakage: src/sbin/ifconfig
Makoto Matsushita [EMAIL PROTECTED] writes: With 5-current as of Dec/04/2001 15:00:00 GMT. It seems that this is because 'WARNS=0' line is inside of !defined(RELEASE_CRUNCH) clause. IMO, if an application's code requires to set 'WARNS=0 for build, it should also be set when building as a part of a crunched binary. Should be fixed now. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
$B$*@$OC$K$J$j$^$9(B
$BLLGr$$$h!"C/$K$bCN$i$l$:0B?4!"=w@-$O40A4(B $BL5NA%-%c%C%7%e%P%C%/$,$"$k$h!*CK@-$*;n$7(B $BIU$-0lEY;n$7$F$_$F$M!*!*(B To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: procfs requires pseudofs
I forgot to mention that procfs now requires pseudofs, so those of you who have 'options PROCFS' in your kernel config will have to add 'options PSEUDOFS' if it's not there already. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Possible libc_r pthread bug
Alfred Perlstein wrote: * Daniel Eischen [EMAIL PROTECTED] [011130 16:17] wrote: On Fri, 30 Nov 2001, Louis-Philippe Gagnon wrote: If at first you don't succeed... I've encountered a problem using pthread_cancel, pthread_join and pthread_setcanceltype, I'm hoping someone can shed some light. (in a nutshell : pthread_setcanceltype doesn't seem to work in FreeBSD 4.4) (posted to -current and -hackers; if there's a more appropriate mailing list for this, please let me know) I recently encountered a situation where, after calling pthread_cancel to cancel a thread, the call to pthread_join hangs indefinitely. I quickly figured out that it was because the thread being cancelled was never reaching a cancellation point (in fact it was an infinite loop with no function calls at all). Sure enough, adding a pthread_testcancel() in the loop allowed pthread_join to return. However this solution isn't acceptable for my requirements. please test the following patch: There are already cancellation tests when resuming threads whose contexts are not saved as a result of a signal interrupt (ctxtype != CTX_UC). You shouldn't test for cancellation when ctxtype == CTX_UC because you are running on the scheduler stack, not the threads stack. You also have a bug in the way you changed the check for cancellation flags. There only clean way to fix this is to add a return frame to the interrupted context so that it can check for cancellation (and other things) before returning to the threads interrupted context. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Possible libc_r pthread bug
* Dan Eischen [EMAIL PROTECTED] [011204 06:26] wrote: There are already cancellation tests when resuming threads whose contexts are not saved as a result of a signal interrupt (ctxtype != CTX_UC). You shouldn't test for cancellation when ctxtype == CTX_UC because you are running on the scheduler stack, not the threads stack. That makes sense, but why? You also have a bug in the way you changed the check for cancellation flags. What? There only clean way to fix this is to add a return frame to the interrupted context so that it can check for cancellation (and other things) before returning to the threads interrupted context. No way to work around this? Shouldn't the thread exit library know which stack exactly to clean up even in the context of a signal handler? -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Possible libc_r pthread bug
* Alfred Perlstein [EMAIL PROTECTED] [011204 11:45] wrote:
* Dan Eischen [EMAIL PROTECTED] [011204 06:26] wrote:
There are already cancellation tests when resuming threads
whose contexts are not saved as a result of a signal interrupt
(ctxtype != CTX_UC). You shouldn't test for cancellation when
ctxtype == CTX_UC because you are running on the scheduler
stack, not the threads stack.
That makes sense, but why?
You also have a bug in the
way you changed the check for cancellation flags.
What?
There only clean way to fix this is to add a return frame
to the interrupted context so that it can check for cancellation
(and other things) before returning to the threads interrupted
context.
No way to work around this? Shouldn't the thread exit library
know which stack exactly to clean up even in the context of a
signal handler?
Are you sure this is 100% needed?
Here's a recap of that patch, are you saying that the problem
is that the thread will use the current sp if it exits rather
than some value stashed away in the private pthread struct?
Also, I think my tests for cancellation are correct. Although
I sort of think the PTHREAD_AT_CANCEL_POINT test should be
removed because the code will catch this when it leaves the
cancellation point.
Index: uthread_kern.c
===
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_kern.c,v
retrieving revision 1.39
diff -u -r1.39 uthread_kern.c
--- uthread_kern.c 7 Oct 2001 02:34:43 - 1.39
+++ uthread_kern.c 4 Dec 2001 17:58:31 -
@@ -180,7 +180,7 @@
struct pthread *curthread = _get_curthread();
pthread_t pthread, pthread_h;
unsigned intcurrent_tick;
- int add_to_prioq;
+ int add_to_prioq, cfl;
/* If the currently running thread is a user thread, save it: */
if ((curthread-flags PTHREAD_FLAGS_PRIVATE) == 0)
@@ -604,6 +604,15 @@
*/
_thread_kern_in_sched = 0;
+ /*
+* test for async cancel:
+*/
+ cfl = curthread-cancelflags;
+
+ cfl = (PTHREAD_CANCEL_ASYNCHRONOUS|
+ PTHREAD_AT_CANCEL_POINT);
+ if (cfl != 0)
+ pthread_testcancel();
#if NOT_YET
_setcontext(curthread-ctx.uc);
#else
@@ -1078,6 +1087,8 @@
curthread-sig_defer_count--;
}
else if (curthread-sig_defer_count == 1) {
+ int cfl;
+
/* Reenable signals: */
curthread-sig_defer_count = 0;
@@ -1091,8 +1102,9 @@
* Check for asynchronous cancellation before delivering any
* pending signals:
*/
- if (((curthread-cancelflags PTHREAD_AT_CANCEL_POINT) == 0)
- ((curthread-cancelflags PTHREAD_CANCEL_ASYNCHRONOUS) != 0))
+ cfl = curthread-cancelflags;
+ cfl = (PTHREAD_CANCEL_ASYNCHRONOUS|PTHREAD_AT_CANCEL_POINT);
+ if (cfl != 0)
pthread_testcancel();
/*
--
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using 1970s technology,
start asking why software is ignoring 30 years of accumulated wisdom.'
http://www.morons.org/rants/gpl-harmful.php3
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Possible libc_r pthread bug
Alfred Perlstein wrote: * Dan Eischen [EMAIL PROTECTED] [011204 06:26] wrote: There are already cancellation tests when resuming threads whose contexts are not saved as a result of a signal interrupt (ctxtype != CTX_UC). You shouldn't test for cancellation when ctxtype == CTX_UC because you are running on the scheduler stack, not the threads stack. That makes sense, but why? Because when a thread gets cancelled, pthread_exit gets called which then calls the scheduler again. It is also possible to get interrupted during this process and the threads context (which is operating on the scheduler stack) could get saved. The scheduler could get entered again, and if the thread gets resumed, it'll longjmp to the saved context which is the scheduler stack (and which was just trashed by entering the scheduler again). It is too confusing to try to handle conditions like this, and the threads library doesn't need to get any more confusing ;-) Once the scheduler is entered, no pthread routines should be called and the scheduler should not be recursively entered. The only way out of the scheduler should be a longjmp or sigreturn to a saved threads context. You also have a bug in the way you changed the check for cancellation flags. What? When a thread is at a cancellation point, you want to let the cancellable routine handle the cancel. The check as coded before avoided calling pthread_testcancel() when at a cancellation point. I think you check for either PTHREAD_AT_CANCEL_POINT or PTHREAD_CANCEL_ASYNCHRONOUS being set when you really want ((flags PTHREAD_AT_CANCEL_POINT) == 0) ((flags PTHREAD_CANCEL_ASYNCHRONOUS) != 0)) There only clean way to fix this is to add a return frame to the interrupted context so that it can check for cancellation (and other things) before returning to the threads interrupted context. No way to work around this? Shouldn't the thread exit library know which stack exactly to clean up even in the context of a signal handler? It assumes that you're running on the current threads stack. I don't view this particular bug as a big problem. It is a somewhat perverse program that has a CPU bound thread that never gets to any sort of blocking condition and yet still wants to be cancelled. The submitter of the problem doesn't even want to upgrade to get a fix. It can be worked around easily enough by checking for cancellation or by using pthread_kill to send a signal to the thread and have the signal handler exit the thread or longjmp back to the thread at a place that can exit and cleanup. There is already a minor race condition in trying to resume a thread that was interrupted by a signal. Adding some code to munge the stack of an interrupted context so that it calls a wrapper function would solve both problems. The signal handling code already does this to install a signal handler wrapper on a threads stack. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Possible libc_r pthread bug
* Daniel Eischen [EMAIL PROTECTED] [011204 12:32] wrote:
Alfred Perlstein wrote:
* Dan Eischen [EMAIL PROTECTED] [011204 06:26] wrote:
There are already cancellation tests when resuming threads
whose contexts are not saved as a result of a signal interrupt
(ctxtype != CTX_UC). You shouldn't test for cancellation when
ctxtype == CTX_UC because you are running on the scheduler
stack, not the threads stack.
That makes sense, but why?
Because when a thread gets cancelled, pthread_exit gets called
which then calls the scheduler again. It is also possible to
get interrupted during this process and the threads context
(which is operating on the scheduler stack) could get saved.
The scheduler could get entered again, and if the thread
gets resumed, it'll longjmp to the saved context which is the
scheduler stack (and which was just trashed by entering the
scheduler again).
It is too confusing to try to handle conditions like this, and
the threads library doesn't need to get any more confusing ;-)
Once the scheduler is entered, no pthread routines should
be called and the scheduler should not be recursively
entered. The only way out of the scheduler should be a
longjmp or sigreturn to a saved threads context.
Ok, for the sake of beating a clue into me...
in uthread_kern.c:_thread_kern_sched
/* Save the state of the current thread: */
if (_setjmp(curthread-ctx.jb) == 0) {
/* Flag the jump buffer was the last state saved: */
curthread-ctxtype = CTX_JB_NOSIG;
curthread-longjmp_val = 1;
} else {
DBG_MSG(Returned from ___longjmp, thread %p\n,
curthread);
/*
* This point is reached when a longjmp() is called
* to restore the state of a thread.
*
* This is the normal way out of the scheduler.
*/
_thread_kern_in_sched = 0;
if (curthread-sig_defer_count == 0) {
if (((curthread-cancelflags
PTHREAD_AT_CANCEL_POINT) == 0)
((curthread-cancelflags
PTHREAD_CANCEL_ASYNCHRONOUS) != 0))
/*
* Cancellations override signals.
*
* Stick a cancellation point at the
* start of each async-cancellable
* thread's resumption.
*
* We allow threads woken at cancel
* points to do their own checks.
*/
pthread_testcancel();
}
Why isn't this working, shouldn't it be doing the right thing?
What if curthread-sig_defer_count wasn't tested?
Maybe this should be a test against curthread-sig_defer_count = 1?
I'll play with this some more when I get back to my box at home,
it just seems bizarro to me.
--
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using 1970s technology,
start asking why software is ignoring 30 years of accumulated wisdom.'
http://www.morons.org/rants/gpl-harmful.php3
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Possible libc_r pthread bug
Alfred Perlstein wrote:
* Daniel Eischen [EMAIL PROTECTED] [011204 12:32] wrote:
Alfred Perlstein wrote:
* Dan Eischen [EMAIL PROTECTED] [011204 06:26] wrote:
There are already cancellation tests when resuming threads
whose contexts are not saved as a result of a signal interrupt
(ctxtype != CTX_UC). You shouldn't test for cancellation when
ctxtype == CTX_UC because you are running on the scheduler
stack, not the threads stack.
That makes sense, but why?
Because when a thread gets cancelled, pthread_exit gets called
which then calls the scheduler again. It is also possible to
get interrupted during this process and the threads context
(which is operating on the scheduler stack) could get saved.
The scheduler could get entered again, and if the thread
gets resumed, it'll longjmp to the saved context which is the
scheduler stack (and which was just trashed by entering the
scheduler again).
It is too confusing to try to handle conditions like this, and
the threads library doesn't need to get any more confusing ;-)
Once the scheduler is entered, no pthread routines should
be called and the scheduler should not be recursively
entered. The only way out of the scheduler should be a
longjmp or sigreturn to a saved threads context.
Ok, for the sake of beating a clue into me...
in uthread_kern.c:_thread_kern_sched
/* Save the state of the current thread: */
if (_setjmp(curthread-ctx.jb) == 0) {
/* Flag the jump buffer was the last state saved: */
curthread-ctxtype = CTX_JB_NOSIG;
curthread-longjmp_val = 1;
} else {
DBG_MSG(Returned from ___longjmp, thread %p\n,
curthread);
/*
* This point is reached when a longjmp() is called
* to restore the state of a thread.
*
* This is the normal way out of the scheduler.
*/
_thread_kern_in_sched = 0;
if (curthread-sig_defer_count == 0) {
if (((curthread-cancelflags
PTHREAD_AT_CANCEL_POINT) == 0)
((curthread-cancelflags
PTHREAD_CANCEL_ASYNCHRONOUS) != 0))
/*
* Cancellations override signals.
*
* Stick a cancellation point at the
* start of each async-cancellable
* thread's resumption.
*
* We allow threads woken at cancel
* points to do their own checks.
*/
pthread_testcancel();
}
Why isn't this working, shouldn't it be doing the right thing?
What if curthread-sig_defer_count wasn't tested?
Maybe this should be a test against curthread-sig_defer_count = 1?
Because this is the normal way into the scheduler -- when a thread
hits a blocking condition or yields. A signal interrupting a thread
does not go through this section. The interrupted threads context is
argument 3 of the signal handler, and this context gets stored in
curthread-ctx.uc. This is the crux of the problem. When you resume
this context, you are not in the thread scheduling code and so you
can't check for cancellation. I'm suggesting that the proper way
to handle this is to munge this interrupted context (a ucontext_t)
so that it first returns to a small wrapper function that can
check for cancellation (and clear the in scheduler flag which
is the other problem I mentioned) before returning to the interrupted
context.
There is another way to handle this, but it is more complicated
although probably better than the above method. This would involve
changing the signal handling code to not use an alternate signal
stack, so an interrupted thread could do something like:
void
sighandler(int sig, siginfo_t *info, ucontext_t *ucp)
{
...
{
ucontext_t uc;
/* Save interrupted context on stack: */
uc = *ucp;
uc.uc_sigmask = _process_sigmask;
/* Enter the scheduler: */
_thread_kern_sched(NULL);
/*
* After return from the scheduler, the
* in scheduler flag
Re: HEADS UP: truss(1) out of commission
Bruce Evans [EMAIL PROTECTED] writes: Please only commit working code. Tell that to the author of truss(1) (who also wrote procfs(5) in the first place). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Possible libc_r pthread bug
* Daniel Eischen [EMAIL PROTECTED] [011130 16:17] wrote:
On Fri, 30 Nov 2001, Louis-Philippe Gagnon wrote:
If at first you don't succeed...
I've encountered a problem using pthread_cancel, pthread_join and
pthread_setcanceltype, I'm hoping someone can shed some light.
(in a nutshell : pthread_setcanceltype doesn't seem to work in FreeBSD 4.4)
(posted to -current and -hackers; if there's a more appropriate mailing list
for this, please let me know)
I recently encountered a situation where, after calling pthread_cancel to
cancel a thread, the call to pthread_join hangs indefinitely. I quickly figured
out that it was because the thread being cancelled was never reaching a
cancellation point (in fact it was an infinite loop with no function calls at
all).
Sure enough, adding a pthread_testcancel() in the loop allowed
pthread_join to return. However this solution isn't acceptable for my requirements.
please test the following patch:
Index: uthread/uthread_kern.c
===
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_kern.c,v
retrieving revision 1.39
diff -u -r1.39 uthread_kern.c
--- uthread/uthread_kern.c 7 Oct 2001 02:34:43 - 1.39
+++ uthread/uthread_kern.c 4 Dec 2001 08:22:22 -
@@ -579,6 +579,18 @@
curthread);
}
/*
+* If the currently running thread is a user thread,
+* test for async cancel:
+*/
+ if ((curthread-flags PTHREAD_FLAGS_PRIVATE) == 0) {
+ int cfl = curthread-cancelflags;
+
+ cfl = (PTHREAD_CANCEL_ASYNCHRONOUS|
+ PTHREAD_AT_CANCEL_POINT);
+ if (cfl != 0)
+ pthread_testcancel();
+ }
+ /*
* Continue the thread at its current frame:
*/
switch(curthread-ctxtype) {
@@ -1078,6 +1090,8 @@
curthread-sig_defer_count--;
}
else if (curthread-sig_defer_count == 1) {
+ int cfl;
+
/* Reenable signals: */
curthread-sig_defer_count = 0;
@@ -1091,8 +1105,9 @@
* Check for asynchronous cancellation before delivering any
* pending signals:
*/
- if (((curthread-cancelflags PTHREAD_AT_CANCEL_POINT) == 0)
- ((curthread-cancelflags PTHREAD_CANCEL_ASYNCHRONOUS) != 0))
+ cfl = curthread-cancelflags;
+ cfl = (PTHREAD_CANCEL_ASYNCHRONOUS|PTHREAD_AT_CANCEL_POINT);
+ if (cfl != 0)
pthread_testcancel();
/*
--
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using 1970s technology,
start asking why software is ignoring 30 years of accumulated wisdom.'
http://www.morons.org/rants/gpl-harmful.php3
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
