I think the only changes I'd make is to not make the variables in
SysSemaphore public and define methods for the different operations
that might change/test the state.
Rick
On Fri, Feb 5, 2010 at 1:14 PM, Mark Miesfeld wrote:
> On Fri, Feb 5, 2010 at 2:00 AM, Rick McGuire wrote:
>
>> This actua
On Fri, Feb 5, 2010 at 2:00 AM, Rick McGuire wrote:
> This actually looks better, but I suspect that the hang is now
> occurring because the reentrant windows proc is creating a condition
> where this thread is never getting a chance to be woken up. I didn't
> really expect this chance to make t
This actually looks better, but I suspect that the hang is now
occurring because the reentrant windows proc is creating a condition
where this thread is never getting a chance to be woken up. I didn't
really expect this chance to make the oodialog problem go way, but
rather to keep the internal in
Rick,
I tried your last commit. I can still get the same hang.
(By the way, I coded up the thread local storage alternate solution
and it seems to work nicely. I'll post on that later.)
Here is the stack trace from the RexxDlgProc thread, on 64-bit
Windows. It's long, but go all the way to th
On Thu, Feb 4, 2010 at 5:40 AM, Rick McGuire wrote:
> There's one additional thing we might consider implementing here. The
> waiting activities queue is implemented using a linked list where the
> link fields are directly contained within the activity object. This
> causes problems if there is
On Thu, Feb 4, 2010 at 1:47 AM, Rick McGuire wrote:
> On Wed, Feb 3, 2010 at 11:32 PM, Mark Miesfeld wrote:
>> What I was thinking was: for the C++ API, add an API for AttachThread
>> that took a parameter which marked the activity for that thread to
>> avoid PeekMessage. Them from ActivityMan
There's one additional thing we might consider implementing here. The
waiting activities queue is implemented using a linked list where the
link fields are directly contained within the activity object. This
causes problems if there is a reentrant situation that can cause the
same activity to be
On Wed, Feb 3, 2010 at 11:32 PM, Mark Miesfeld wrote:
> Rick
>
> (For some reason your mail didn't show up until hours after you sent it.)
>
> I have a solution that, so far, in all my testing seems to work. I'm
> not sure how to fully implement it, or if it is feasible. It has two
> parts:
>
>
Rick
(For some reason your mail didn't show up until hours after you sent it.)
I have a solution that, so far, in all my testing seems to work. I'm
not sure how to fully implement it, or if it is feasible. It has two
parts:
1.) I think this is feasible and indeed I think should probably be
do
Mark,
I see a little bit of what's going on, but these stack traces are not
making much sense to me. The dialog message threads make sense, but
the stacks for the other threads don't make much sense.
There is one common factor I see here, and that's all the trouble
seems to start with a call to
Rick,
When you get a chance could you take a look at this problem. I'm
going to send you a zip file with some stack traces and a test
program.
This is related to / similar to the problem we were discussing a week
or so ago. Similar in that it has to do with the C++ API and using
AttachThread()
11 matches
Mail list logo
