* Seigo Tanimura <[EMAIL PROTECTED]> [010711 01:39] wrote:
> On Wed, 11 Jul 2001 10:44:21 +0900,
> Seigo Tanimura <[EMAIL PROTECTED]> said:
>
> Alfred> I'm also quite sure that you can't call the ktrace functions with
> Alfred> any mutexes held so the code is doing to need some help, basically
> Alfred> the trick in trapsig() and postsig() is to generate the ktrace
> Alfred> IO after the locks have been dropped, this means somehow caching
> Alfred> the info sent to ktrace where it's currently called, and calling
> Alfred> it later with the cached info after the locks are dropped.
>
> Seigo> We can cache ktrace information into struct proc and mark the
> Seigo> existence of cache in p_traceflag. Then we send the information to
> Seigo> ktrace upon returning from trapsignal() or CURSIG(), or in sigexit().
>
> The problem has turned out to be even worse.
>
> msleep() and cv_*wait*() might receive a mutex held by curproc. As we
> cannot release the mutex to sleep in ktrwrite() during msleep() or
> cv_*wait*(), it is also necessary to cache information sent to
> ktrcsw().
>
> Is it not feasible to examine the existence of cached ktrcsw()
> information upon every single call of msleep() and cv_*wait*() in
> order to flush the cached information. Instead of that, we should
> watch for release of mutexes. When a process no longer holds any
> mutexes except for Giant, it is safe to flush cached information to
> ktrace.
Yes, it's pretty gross. :(
--
-Alfred Perlstein [[EMAIL PROTECTED]]
Ok, who wrote this damn function called '??'?
And why do my programs keep crashing in it?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
