:On Mon, 14 Jul 2008, Matthew Dillon wrote:
:
:>     Please try the following patch to libthread_xu and tell me if it
:>     fixes firefox:
:>
:>     fetch http://apollo.backplane.com/DFlyMisc/schedp01.patch
:
:Yes, it works for me.  Thanks to Jordan for tracking this down!

    Ok, I've committed it.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

On Mon, 14 Jul 2008, Matthew Dillon wrote:

Yes, it works for me.  Thanks to Jordan for tracking this down!

for the record, this seems to be related to

http://bugs.dragonflybsd.org/issue622

cheers
   simon

Please try the following patch to libthread_xu and tell me if it
    fixes firefox:

    fetch http://apollo.backplane.com/DFlyMisc/schedp01.patch

					-Matt

:...
:> THR_MAX_PRIORITY(31), both defined in 
:> lib/libthread_xu/thread/thr_private.h. When a value in the range [-20; 
:> -1] is used, pthread_attr_setschedparam returns an error code of 
:> ENOTSUPP, which NSPR doesn't like. More precisely, when Firefox is 
:> compiled with the 'debug' pkgsrc option, an assert fails, abort() is 
:> called and a coredump written.
:
:I thought we had fixed that some time ago already?

     Nope, I'm looking at the code and it is definitely a problem.  There
     are a bunch of THR_ defines that are essentially not used by
     the library at all, except for that (broken) range check.

     The only thing that uses THR_MAX_PRIORITY is the m_ceiling
     attribute in the mutex attribute structure, which we don't use
     at all (and I think it operates in a private scheduling domain
     anyway).

     I'll have a patch for people w/ the firefox setup to try in a moment.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

:I have a Firefox problem caused by DragonFly and/or libthread_xu.
:sched_get_priority_min(SCHED_OTHER) and 
:sched_get_priority_max(SCHED_OTHER) return values PRIO_MIN (-20) and 
:PRIO_MAX(20), both defined in sys/sys/resource.h.
:When pthread_attr_setschedparam is called to set scheduling priority for 
:scheduling policy SCHED_OTHER, the priority value is checked if it is 
:within range by comparing it to THR_MIN_PRIORITY(0) and 
:THR_MAX_PRIORITY(31), both defined in 
:lib/libthread_xu/thread/thr_private.h. When a value in the range [-20; 
:-1] is used, pthread_attr_setschedparam returns an error code of 
:ENOTSUPP, which NSPR doesn't like. More precisely, when Firefox is 
:compiled with the 'debug' pkgsrc option, an assert fails, abort() is 
:called and a coredump written.

    Nice catch.  I'll clean up the priority handling code right now.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

I thought we had fixed that some time ago already?

I have a Firefox problem caused by DragonFly and/or libthread_xu.
sched_get_priority_min(SCHED_OTHER) and 
sched_get_priority_max(SCHED_OTHER) return values PRIO_MIN (-20) and 
PRIO_MAX(20), both defined in sys/sys/resource.h.
When pthread_attr_setschedparam is called to set scheduling priority for 
scheduling policy SCHED_OTHER, the priority value is checked if it is 
within range by comparing it to THR_MIN_PRIORITY(0) and 
THR_MAX_PRIORITY(31), both defined in 
lib/libthread_xu/thread/thr_private.h. When a value in the range [-20; 
-1] is used, pthread_attr_setschedparam returns an error code of 
ENOTSUPP, which NSPR doesn't like. More precisely, when Firefox is 
compiled with the 'debug' pkgsrc option, an assert fails, abort() is 
called and a coredump written.