From: Mark Wielaard <mark@klomp.org>
To: Elena Zannoni <elena.zannoni@oracle.com>
Cc: frysk <frysk@sourceware.org>
Subject: Re: notes ui call 20070214
Date: Thu, 15 Feb 2007 09:53:00 -0000 [thread overview]
Message-ID: <1171533225.3613.27.camel@dijkstra.wildebeest.org> (raw)
In-Reply-To: <45D33830.3070800@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 2441 bytes --]
Hi Elena,
Thanks for taking notes!
On Wed, 2007-02-14 at 11:26 -0500, Elena Zannoni wrote:
> Tim: stop the world or stop individual threads? Right now it's stop the
> world.
> But underlying mechanism to do stop each thread is there.
What you can do at all times is add an Instruction TaskObserver.
* Interface used to notify that a Task has executed a single
* instruction. <code>updateExecuted</code> is called as soon as
* the Instruction observer is added to the Task. And whenever the
* Task starts running again (isn't blocked or suspended) it will
* be called on each instruction being executed.
* <p>
* This TaskObserver can also be used for executing code that
* needs the Task to be (temporarily) blocked or suspended as soon
* as possible. <code>updateExecuted()</code> will be called as
* soon as this observer has been properly added, and at that time
* the Task is suspended to make it possible to inspect the Task
* state. If no other action is request, the method can then just
* delete the observer from the Task again.
> volatile attribute can make a variable stick around even with optimization.
And I only added volatile to make sure they wouldn't get optimized away.
Filed bug report #4048 for this. (Does the fhpd have a tracker bug?)
> Help <command> is totally broken
New bug #4050 This would be really useful!
> compatibility with gdb command set. it's needed, maybe a set of aliases.
New bug #4049
> 2. Request to open up the RH only conf call to all. For general status
> of the project, who works on what, progress reports, and
> dependencies/issue with other components (kernel, gcc, libunwind,
> etc) RH has things that cannot be discussed openly, will need to
> figure out how to avoid having 3 meetings.
Note that "cannot be discussed openly" is more "not very frysk related".
I would vote for less phone talk and more discussion on list by email.
Unless there are very good minutes made and posted (you make great
minutes btw!) there is big chance of things falling through the cracks.
If we discuss some things more on the list (just simple things like
'heay, has anybody recently tried a 2.6.20 kernel? Does it pass our
frysk-import tests?') that would be really good to have an automatic
record for everybody, even if you cannot make a call.
Cheers,
Mark
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2007-02-15 9:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-14 16:29 Elena Zannoni
2007-02-15 9:53 ` Mark Wielaard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1171533225.3613.27.camel@dijkstra.wildebeest.org \
--to=mark@klomp.org \
--cc=elena.zannoni@oracle.com \
--cc=frysk@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).