BrowserUk, not sure if I understood you correctly, I checked for the value returned by Perl_get_context() it returns same value throughout the execution of the program. Therefore I'm in an understanding that there is only one perl interpreter here and only one context. The latest link you provided is close to the issue I'm trying to solve will take a good look and let you know.
Corion, Async::Interrupt() as you suggested looks to be a good solution here. I believe the issue happens only when perl interpreter is forced to do 2 things from 2 threads at race conditions. for ex. "print" from main thread and context switches to "print" from callback subroutine. I suspect the call_pv() function in wrap_connect_cback_handler() function is NOT reentrant in nature (some others may not be as well.)
Meanwhile, I tried Win32::Event to wait for callback in the main thread. The event is Set at the end of the callback subroutine. It worked fantastic. This approach has more overhead than Async::Interrupt() for an event driven scenario albeit simpler.
Thanks.In reply to Re^2: Perl interpreter throws strange errors for event-driven callback processing under race conditions
by Cotton4Lunch
in thread Perl interpreter throws strange errors for event-driven callback processing under race conditions
by Cotton4Lunch
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |