On Tue, 27 Sep 2005 08:45:07 MDT, "Davda, Bhavesh P (Bhavesh)" said: > Then propose an alternative way where a real-time (SCHED_FIFO/SCHED_RR) > CPU bound application getting lots of SEGVs for normal operation doesn't If it's RT, *and* CPU-bound, *and* tossing enough SEGV's to matter, it's a train wreck waiting to happen. If something attaches to that locomotive with a ptrace(), making sure that a SEGV doesn't cause a priority inversion merely delays the wreck until the *next* thing the debugger is interested in. What's *next*, prohibit the overhead of whatever "stop at" or "trace value" command the debugger has? By the time you clean all of that stuff up, you're basically left with "why bother allowing a ptrace()?".
Attachment:
pgpExcBRn7nmt.pgp
Description: PGP signature
- References:
- RE: [RFC PATCH] New SA_NOPRNOTIF sigaction flag
- From: "Davda, Bhavesh P \(Bhavesh\)" <[email protected]>
- RE: [RFC PATCH] New SA_NOPRNOTIF sigaction flag
- Prev by Date: Re: [PATCH][Fix] Fix Bug #4959 (take 2)
- Next by Date: Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
- Previous by thread: Re: [RFC PATCH] New SA_NOPRNOTIF sigaction flag
- Next by thread: RE: [RFC PATCH] New SA_NOPRNOTIF sigaction flag
- Index(es):