Hi Shawn,
I use 64-bit linux and I see this issue a lot. It usually manifests
itself as the prompt just not being printed (or perhaps it just gets
overwritten) - regardless - I invoke a command, and I don't see an
(lldb) prompt when I should. So I'm well pleased that you are looking at
this!
Would it not be more robust to use a semaphore than usleep to
synchronise the problematic threads?
Although I've not looked too deeply into this particular issue, whenever
I've seen similar races, I found that it's almost impossible to pick the
right value when using a sleep command. A semaphore, though, should
always ensure the waiting thread will wake precisely.
I'd be happy to help to test such a fix.
Matt
Shawn Best wrote:
Hi,
I have attached a patch which addresses 3 related race conditions that
cause the command line (lldb) prompt to get displayed inappropriately
and make it appear it is not working correctly. This issue can be
seen on linux and FreeBSD. I can also artificailly induce the problem
on OSX.
The issue happens when the command handler (in the main thread) issues
a command such as run, step or continue. After the command finishes
initiating its action, it returns up the call stack and goes back into
the main command loop waiting for user input. Simultaneously, as the
inferior process starts up, the MonitorChildProcess thread picks up
the change and posts to the PrivateEvent thread. HandePrivateEvent()
then calls PushProcessIOHandler() which will disable the command IO
handler and give the inferior control of the TTY. To observe this on
OSX, put a
usleep(100);
immediately prior the PushProcessIOHandler() in HandlePrivateEvent.
My proposed solution is that after a 'run', 'step', or 'continue'
command, insert a synchronization point and wait until
HandlePrivateEvent knows the inferior process is running and has
pushed the IO handler. One context switch (<100us) is usually all the
time it takes on my machine. As an additional safety, I have a
timeout (currently 1ms) so it will never hang the main thread.
Any thoughts, or suggestions would be appreciated.
Regards,
Shawn.
To report this email as spam click here
<https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==>.
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
Member of the CSR plc group of companies. CSR plc registered in England and
Wales, registered number 4187346, registered office Churchill House, Cambridge
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our
technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube,
www.youtube.com/user/CSRplc, Facebook,
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at
www.aptx.com.
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
