Hard switching immediately switches by changing the stack contents. And soft switching has the function you call return an unwind token which should be propagated back through the call chain to the scheduler. If you ignore this, and throw it away, it has caused crash problems in the past. Of course, with the approach you've taken, there's no way it can be returned out of that event and back through the call chain. You can try and call the versions of the api which do not soft switch, these might be documented in the documentation.
Cheers, Richard. On 9/10/14, Robert Babiak <[email protected]> wrote: > oh the actual break message > > Process 53817 stopped > > * thread #5: tid = 0x1c027f, 0x0000000100ea30a3 Python`PyStackless_Schedule > + 51, stop reason = EXC_BAD_ACCESS (code=1, address=0xd8) > > frame #0: 0x0000000100ea30a3 Python`PyStackless_Schedule + 51 > > Python`PyStackless_Schedule + 51: > > -> 0x100ea30a3: movq 0xd8(%r13), %rbx > > 0x100ea30aa: movq 0x10(%rbx), %r12 > > 0x100ea30ae: movq $0x0, -0x30(%rbp) > > 0x100ea30b6: cmpq $0x0, 0xd0(%r13) > > On Tue, Sep 9, 2014 at 9:57 PM, Robert Babiak <[email protected]> wrote: > >> I took the Receive out and replaced it with a simple call to >> PyStackless_Schedule. >> >> static int EventHook(void) >> { >> PyStackless_Schedule(Py_None, 0); >> return 0; >> } >> ... >> Py_SetProgramName(argv[0]); >> Py_InitializeEx(0); >> if (!Py_IsInitialized()) >> { >> std::cerr << "Python initialization failed" << std::endl; >> return; >> } >> PySys_SetArgv(argc, argv); >> PyOS_InputHook = EventHook; >> ... >> // stacklessMain returns when program is shutdown. >> PyStackless_CallMethod_Main(oMainModule.ptr(), "stacklessMain", >> 0); >> ... >> >> This is the lldb stacktrace >> >> frame #0: 0x0000000100ea30a3 Python`PyStackless_Schedule + 51 >> >> frame #1: 0x0000000100155fd9 main`EventHook() + 25 at >> pythonInterperter.cpp:472 >> >> frame #2: 0x0000000103dd5e25 readline.so`call_readline + 293 >> >> frame #3: 0x0000000100dfa3c3 Python`PyOS_Readline + 179 >> >> frame #4: 0x0000000100e92882 Python`builtin_raw_input + 434 >> >> frame #5: 0x0000000100e95d88 Python`PyEval_EvalFrame_value + 3832 >> >> frame #6: 0x0000000100e94d38 Python`PyEval_EvalFrameEx_slp + 376 >> >> frame #7: 0x0000000100e9744c Python`PyEval_EvalFrame_value + 9660 >> >> frame #8: 0x0000000100e94d38 Python`PyEval_EvalFrameEx_slp + 376 >> >> frame #9: 0x0000000100e9744c Python`PyEval_EvalFrame_value + 9660 >> >> frame #10: 0x0000000100e94d38 Python`PyEval_EvalFrameEx_slp + 376 >> >> frame #11: 0x0000000100e9e9e1 Python`slp_frame_dispatch_top + 49 >> >> frame #12: 0x0000000100ea2772 Python`slp_run_tasklet + 226 >> >> frame #13: 0x0000000100e9e0fc Python`slp_eval_frame + 348 >> >> frame #14: 0x0000000100e9e083 Python`slp_eval_frame + 227 >> >> frame #15: 0x0000000100e9e083 Python`slp_eval_frame + 227 >> >> ..... >> >> frame #719: 0x0000000100e9e083 Python`slp_eval_frame + 227 >> >> frame #720: 0x0000000100e9e083 Python`slp_eval_frame + 227 >> >> frame #721: 0x0000000100ea3801 Python`PyStackless_CallMethod_Main + >> 433 >> >> frame #722: 0x00000001001588e3 >> main`PythonThread::operator(this=0x0000000101506940)() + 1187 at >> pythonInterperter.cpp:555 >> >> frame #723: 0x000000010015761c >> main`boost::detail::thread_data<PythonThread>::run(this=0x0000000101506740) >> + 28 at thread.hpp:117 >> >> frame #724: 0x00000001010ff24a libboost_thread-mt.dylib`thread_proxy >> + >> 186 >> >> frame #725: 0x00007fff863fb899 libsystem_pthread.dylib`_pthread_body >> + >> 138 >> >> frame #726: 0x00007fff863fb72a libsystem_pthread.dylib`_pthread_start >> + 137 >> >> On Tue, Sep 9, 2014 at 9:17 PM, Richard Tew <[email protected]> >> wrote: >> >>> If you have a crash when you call receive, then you likely have larger >>> problems than when the right time to call schedule is. >>> >>> I don't think it's possible to divine what is going wrong, and expect >>> you need to provide a reproduction case. >>> >>> Cheers >>> >>> On 9/10/14, Robert Babiak <[email protected]> wrote: >>> > Dear wise stackless list, I need some of your wisdom. >>> > >>> > I am trying to make raw_input play nice with the stackless scheduler >>> > and >>> > not block with my embedded stackless. >>> > >>> > I set the PyOS_InputHook to get what amounts to an idle event but when >>> > I >>> > call PyStackless_Schedule(PY_None, 0) it crashes (no stackless >>> symbols...) >>> > >>> > Is there something I need to check to know if it is safe to call the >>> > scheduler from C? >>> > >>> > In general when is it safe to call PyStackless_Schedule? >>> > >>> > I tried to call my BeNice to block and get woken up later, but this >>> > also >>> > crashes when trying to receive on my BeNice channel. >>> > >>> > - Thanks Rob. >>> > -- >>> > Life: Bah, I will worry about it when it is over. >>> > >>> >>> _______________________________________________ >>> Stackless mailing list >>> [email protected] >>> http://www.stackless.com/mailman/listinfo/stackless >>> >> >> >> >> -- >> Life: Bah, I will worry about it when it is over. >> > > > > -- > Life: Bah, I will worry about it when it is over. > _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
