On Thu, Aug 29, 2002 at 05:45:09PM -0400, Paul Davis wrote:
> the bug-in-the-code case is handled using the monitor thread approach,
> since we know that the monitored threads run at lower priority.
assuming the bug isn't in the monitor thread itself (or which affects
it).
you can argue that yo
>> a side note: JACK, when run in RT mode, launches its own maximal
>> priority thread to perform exactly this function. all other RT threads
>> run at lower priorities. i believe that it is not possible to use JACK
>> to perform DOS attacks like this unless the client modifies its
>> scheduling p
/wrote Stefan Westerfeld <[EMAIL PROTECTED]> [Thu, 29 Aug 2002 21:16:59
+0200]
| Hi!
|
|On Wed, Aug 28, 2002 at 10:15:54AM -0400, Paul Davis wrote:
|> a side note: JACK, when run in RT mode, launches its own maximal
|> priority thread to perform exactly this function. all other RT threads
|> ru
Hi!
On Wed, Aug 28, 2002 at 10:15:54AM -0400, Paul Davis wrote:
> a side note: JACK, when run in RT mode, launches its own maximal
> priority thread to perform exactly this function. all other RT threads
> run at lower priorities. i believe that it is not possible to use JACK
> to perform DOS
Hi!
On Wed, Aug 28, 2002 at 12:47:41PM -0400, rm wrote:
> which is still an issue. relying on the courtesy of user programs is
> probably not optimal (as i'm sure you're all well aware).
>
> [...]
>
> i've been working on a kernel patch that will allow a program to use
> the entire cpu up
(nb. among other things, this release fixes the problem where Sweep's
configure complained about libsndfile-1.0.0 being too old ... also take
note of the PKG_CONFIG_PATH thing below, which has bitten many people)
Sweep 0.5.1 Development Release
---
Sweep is a sound wa
