ation.
So use something this or change the application's threading model
(like my previous post showed). There's no use complaining about
the Pthreads implementation in this regard because your application's
use of mutexes is the exception, not the rule. The fact that Linux
be
, but I'm pretty sure it's a solid
solution.
The key here is unifying the two input sources (the GUI and work queues)
without blocking on either one of them individually. The value of
(wq.stuff_todo < 1) becomes a proxy for the value of
(gui_queue_empty(...) && work_queue_empt
ture
of your application could be designed in a different manner that
avoids this problem (probably the more difficult fix).
Brent
--
Brent Casavant Dance like everybody should be watching.
www.angeltread.org
KD5EMB, EN34lv
___
freebsd
On Fri, 6 Oct 2006, Albert Shih wrote:
> From someday I've some very strange thing sometime my /dev/null just
> vanish.
>
> Anyone have this problem ?
Not with FreeBSD in particular. However, from time to time I've
run across a piece of software that makes bad assumptions about
deleting var
On Thu, 17 Aug 2006, Dan Nelson wrote:
> In the last episode (Aug 17), Brent Casavant said:
> > Note that IRIX's top does not bias for availabile CPUs -- I've seen
> > well-threaded programs using in excess of 2400% CPU.
> >
> > What it comes down to i
rix/Solaris mode
There's really not a clear cut right and wrong here, particularly if
your version of top is able to display per-thread instead of per-process
data. Sometimes you want to break out individual threads and see their
level of CPU utilization (the IRIX view is most usef
's beyond the scope
of the survey. Thanks for taking the time put the survey together, I
certainly hope it proves useful.
Thank you,
Brent Casavant
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ld
be best to start my hunt in /usr/src/dev/fb/* as opposed to
/usr/src/dev/syscons/* ?
Thanks,
Brent Casavant
--
Brent Casavant Dance like everybody should be watching.
www.angeltread.org
KD5EMB, EN34lv
___
freebsd-stable@freebsd.org
rox Graphics, Inc.: Unknown device 0d43
Flags: bus master, medium devsel, latency 128, IRQ 16
Memory at fc00 (32-bit, prefetchable)
Memory at f820 (32-bit, non-prefetchable)
Memory at f880 (32-bit, non-prefetchable)
Capabilities: [dc] Power Manage
a number of Pthreads
calls in progress (pthread_mutexattr_init, pthread_testcancel, and
pthread_timedwrlock).
I'm casually debugging this problem as time permits, but to no avail
thus far.
Brent
--
Brent Casavant Dance like everyone should
www.angeltread.org
On Wed, 18 May 2005, Peter Jeremy wrote:
> On Tue, 2005-May-17 09:58:33 -0500, Brent Casavant wrote:
> >The only solution I found at that time was reverting to 4.10, though
> >that is obviously suboptimal. I could be persuaded to reinstall 5.x
> >on the machine if I'd
rformance benchmarks and other general stress
tests on the ATA drive, and never was able to manually trigger the
hang.
Anecdotally, a friend of mine who recently tried 5.3 ran into frequent
filesystem/drive problems as well, which reverting to 4.x solved.
However it didn't sound like exactly
at other
times as well, but with nowhere near the same consistency.
The only solution I found at that time was reverting to 4.10, though
that is obviously suboptimal. I could be persuaded to reinstall 5.x
on the machine if I'd be sure to get someone to
13 matches
Mail list logo
