According to the LR, it causes the current thread to sleep for XXXms
- ahhh, in this case, I'd be calling that from the main thread, so
the thread to sleep is the main thread, not the thread I'm waiting
for...
Okay, Just needed a small jiggle to get the synapses firing
properly ... however I tried it yesterday after your suggestion and I
still get the StackOverflow and it does spike the CPU as Mel writes
in his response. With App.DoEvents(), the app stays polite to the
entire system.
The funny thing is that I rebuilt on my previous G5 system and tested
and the process ran for over 5 hours and didn't suffer the problem.
I'm reloading 2006r3 from scratch after a clean removal to see if
something's gone awry in the plugin cache...
Tim
--
Tim Jones [EMAIL PROTECTED]
On Sep 19, 2006, at 9:03 PM, Charles Yeomans wrote:
What do you suppose App.SleepCurrentThread does?
Charles Yeomans
On Sep 19, 2006, at 6:21 PM, Tim Jones wrote:
On Sep 19, 2006, at 2:22 PM, Charles Yeomans wrote:
Try replacing App.DoEvents with App.SleepCurrentThread 100 or so
and see if that fixes things.
I think you've misinterpreted the purpose for that Do -- Loop.
Its's to pause the current event until that thread loop has
finished. Once the shell spits out one of the trapped strings
(the "If InStr(self.mBuffer, "[I") <> 0" stuff), the current shell
is done and no further output will be forthcoming (therefore no
more DataAvailable events) until user interaction occurs. The
pause is to allow the current thread loop to complete before we
enter the thread again since we want to process ALL lines of that
last output (we normally only process the last 5 lines - there
could be hundreds in one event). For this, I felt that a DoEvents
was safe as there shouldn't be an opportunity for recursion in the
DataAvailable event. Either way, I don't want to pause the
thread, I want the current event to pause until the current thread
loop completes.
Therefore, I don't suspect that SleepCurrentThread will give the
result I'm looking for.
Tim
--
Tim Jones [EMAIL PROTECTED]
Charles Yeomans
On Sep 19, 2006, at 5:12 PM, Tim Jones wrote:
On Sep 19, 2006, at 2:03 PM, Charles Yeomans wrote:
Is this in a console app? If not, I'd suspect the call to
App.DoEvents.
Hi Charles,
It's a GUI app.
Good point and I'd already though of that. But, this begs the
question of just how deep that stack is. However. since the
App.DoEvents() is only called on the very last output from the
shell, there shouldn't be an issue as this runs successfully on
shorter runs and is totally unpredictable on the long runs (20
minutes on the first, 2:12 on the second test).
Thanks,
Tim
--
Tim Jones [EMAIL PROTECTED]
Charles Yeomans
On Sep 19, 2006, at 4:54 PM, Tim Jones wrote:
Hi Folks,
Does anyone have a tried and true mechanism for monitoring for
and either fixing or preventing a StackOverflow exception?
I'm monitoring a processing a very long shell process (could
be days), and after unexpected periods the shell's
DataAvailable event throws a StackOverflow exception. The
exception is thrown at the entry to the DataAvailable event.
Here's my code from the DataAvailable event:
------------------------------
Dim x, y, err, mTop As integer
// mBuffer and runData are parent global variables
// thMon2 is the monitor thread for taking the runData and
updating the interface
x = 0
Self.mBuffer = Self.mBuffer + ConvertEncoding(Me.ReadAll,
Encodings.UTF8)
If InStr(self.mBuffer, "[I") <> 0 _
Or InStr(self.mBuffer, "[A") <> 0 _
Or InStr(self.mBuffer, "[Q") <> 0 Then
Debug.Print self.mBuffer
ProcAll = True // We caught a Volume completion message,
so process ALL data
End If
Self.runData = Split(Self.mBuffer, EndOfLine)
If Not ProcAll Then
// take the last line and return it to the mBuffer so the
next ReadAll() completes
// a potentially incomplete line (thanks, Joe!).
Self.mBuffer = Self.runData.Pop
End If
// Process the result
If Self.thMon2.State <> Thread.Running Then
Self.thMon2.Run
ElseIf ProcAll Then
// wait for the current thread loop to complete
While Self.thMon2.State = Thread.Running
App.DoEvents(25)
Wend
Self.thMon2.Run
End If
ProcAll = False
---------------------------------
Am I missing something? This occurs in the built Mach-O
application and in the debugger run.
Tim
--
Tim Jones [EMAIL PROTECTED]
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
