From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Message-id: <045076EF-2053-42B5-A2DD-844E9577D35E@mac.com> From: dave.l@mac.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Date: Fri, 13 Nov 2009 23:47:38 +0000 References: <55c52a87f0b8c0ac12a81a150f110b2b@brasstown.quanstro.net> <20091101184418.GM19125@gradx.cs.jhu.edu> <1257590719.28012.1344036163@webmail.messagingengine.com> <20091110003356.GW19125@gradx.cs.jhu.edu> <13426df10911091646o305d2ab2g664aa719e5b9a0e9@mail.gmail.com> Subject: Re: [9fans] dtrace for plan 9 Topicbox-Message-UUID: 9b84bf1a-ead5-11e9-9d60-3106f5b1d025 > Would this answer your question: > http://blogs.sun.com/jonh/entry/the_dtrace_deadman_mechanism Well, it answers the question "What is the DTrace so-called deadman mechanism?" I think. That's a sort of part of a possible solution, which is OK. To be pedantic, it's not a true deadman mechanism, which operates at the point of failure (incapacity of the driver), not when it's all over (death of the passengers). What's described there is more like a pair of buffers at the end of the crowded terminus station. > Or are you literally trying to figure out the upper bound on the # of > virtual instructions > in a single probe? Well, more importantly, the consequent real-time involved. IOW: assuming you have some common sense (and a degree of chutzpah, given the complexity of the solaris kernel), and thus you have a reasonable idea about how long a time "too long" is to be holding up your kernel, how do you know whether a given D bytecode blob is gonna execute for "too long" or not? D