On Mon, 2004-08-09 at 18:59, Con Kolivas wrote:Albert Cahalan writes:
> Joerg:
> "WARNING: Cannot do mlockall(2).\n"
> "WARNING: This causes a high risk for buffer underruns.\n"
> Fixed:
> "Warning: You don't have permission to lock memory.\n"
> " If the computer is not idle, the CD may be ruined.\n"
> > Joerg:
> "WARNING: Cannot set priority class parameters priocntl(PC_SETPARMS)\n"
> "WARNING: This causes a high risk for buffer underruns.\n"
> Fixed:
> "Warning: You don't have permission to hog the CPU.\n"
> " If the computer is not idle, the CD may be ruined.\n"
Huh? That can't be right. Every cd burner this side of the 21st century has buffer underrun protection.
I'm pretty sure my FireWire CD-RW/CD-R is from
another century. Not that it's unusual in 2004.
I've burnt cds _while_ capturing and encoding video using truckloads of cpu and I/O without superuser privileges, had all the cdrecord warnings and didn't have a buffer underrun.
That's cool. My hardware won't come close to that.
Burning a coaster costs money.
Let me put it this way: $$ $ $$$ $$ $ $$$ $$ $
The warning, if re-worded, will save people from
frustration and wasted money.
Last time I gave superuser privilege to cdrecord it locked my machine - clearly it wasn't rt_task safe.
So, you've been working on the scheduler anyway...
An option to reserve some portion of CPU time for
emergency use (say, 5% after 1 second has passed)
would let somebody get out of this situation.
Reporting and/or fixing the cdrecord bug is nice too.