Some unix systems will hard spin on a delay of less than 10msec. The result
for a cross thread scheduling couid be that the thread communicated 'to'
might
start immediately and hit the lock held by the 'from' thread before it past
posting
the event. If the 'from' thread didn't initialize some of
If anyone is listening to this thread, I have narrowed the problem
down to TSContSchedule(), I can't figure out exactly why it's
happening but when the timeout is very small (either 0 or < 10ms) or
so, it caues MUTEX_TRY_LOCK_FOR to throw a segfault, if I increase the
time to 1000ms it will never h
I should also mention that this never happens on OS X, it only appears
to happen on RHEL.
On Tue, Aug 16, 2011 at 7:41 PM, Leif Hedstrom wrote:
> On 08/16/2011 08:17 PM, Brian Geffon wrote:
>>
>> Hi, for some reason I'm getting a segfault originating in
>> UnixEThread.cc:130 from the macro expans
ATS 3.0.1 on RedHat Enterprise Linux 6.1
On Tue, Aug 16, 2011 at 7:41 PM, Leif Hedstrom wrote:
> On 08/16/2011 08:17 PM, Brian Geffon wrote:
>>
>> Hi, for some reason I'm getting a segfault originating in
>> UnixEThread.cc:130 from the macro expansion of MUTEX_TRY_LOCK_FOR.
>> I've been digging a
On 08/16/2011 08:17 PM, Brian Geffon wrote:
Hi, for some reason I'm getting a segfault originating in
UnixEThread.cc:130 from the macro expansion of MUTEX_TRY_LOCK_FOR.
I've been digging and I can't exactly see where the SEGFAULT is coming
from and I was hoping someone might have an idea of how/w