[haiku-commits] Re: r39846 - in haiku/trunk: headers/os/kernel headers/private/debug headers/private/kernel src/kits/debug src/system/kernel ...
- From: Rene Gollent <anevilyak@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 14 Dec 2010 15:20:39 -0500
On Tue, Dec 14, 2010 at 2:39 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> Yeah, sorry, I'm guilty of suggesting the debugger interface extension in the
> ticket. A listener mechanism definitely is more elegant than polling, but I
> agree with Axel that name or priority changes aren't particarly debugging
> related, nor are debuggers the only applications that might be interested in
> this info. A general listener mechanism for system information would be nicer.
>
Fair enough, what other types of system information would be of
interest for such a listener mechanism?
> Unfortunately it's not that simple. The whole backend
> (thread_hit_debug_event()) cannot be used. The messages must be asynchronous.
> user_debug_thread_deleted() is closer to how that should look. A major
> problem remains, however, that in this case the calling thread should not
> block (particularly when it belongs to another team), which cannot be
> guaranteed, unless one uses timeouts for locking and sending the message,
> which in turn makes those notifications uncertain (unlike all other debugger
> messages).
I think that at least in the short term we can live with that
limitation since instances of one team renaming another's threads are
more the exception than the rule (priorities are not quite as obvious
since e.g. processcontroller makes changing those for another team's
threads quite trivial).
Regards,
Rene
Other related posts:
