Threading module and embedded python

[Barry Scott]

> On 16 Apr 2020, at 14:55, Eko palypse <ekopalypse at gmail.com> wrote:
> 
> Barry, sorry for sending you a private message yesterday, was not intended.
> 
> No, I only have rudimentary knowledge of C++,
> but it has been developing since I started using Cython.
> I haven't done any stack analysis yet but hey, there's always a first time.
> I think my stubbornness could be of help here :-)

Its a very useful when the simple debug stuff fails.

> 
> Visual Studio reports that the last location of the thread is in _ctypes.pyd
> and the call stack window shows that the last execution is
> user32.dll!InternalDailogBox().
> 
> Call Stack
> 
> 
> *user32.dll!InternalDialogBox()user32.dll!DialogBoxIndirectParamAorW()user32.dll!DialogBoxIndirectParamW()_ctypes.pyd!000007fee7fc17e3()_ctypes.pyd!000007fee7fbfee3()_ctypes.pyd!000007fee7fbb4c5()_ctypes.pyd!000007fee7fbc019()_ctypes.pyd!000007fee7fb6dfa()python37.dll!_PyObject_FastCallKeywords(_object
> * callable=0x0000000002fa8c78, _object * const * stack=0x0000000005261c78,
> __int64 nargs=5, _object * kwnames=0x0000000000000000)*

My guess is that you are missing an important parameter to the dialog that allows it be seen.
Test the dialog code outside of the embedded python, with a command line python.
I recall that you have to pass in the parent for a dialog. Maybe in the embedded version
you do not have an HWND that is usable, can NULL be used?
Is there a SHOW arg that you need to pass?

I'd check the MSDN docs for the call you are making and check every param is as required.

(Its been a along time since I did low level win32 in anger so forgive the lack of solutions)


> 
> 
> The thread is neither suspended nor does it have any different status than
> the main thread
> which loops through its main event queue at this point.

It is suspended inside the user32.dll.

Barry

> 
> Thank you
> Eren
> 
> 
> Am Mi., 15. Apr. 2020 um 22:57 Uhr schrieb Barry <barry at barrys-emacs.org>:
> 
>> 
>> 
>>> On 15 Apr 2020, at 21:18, Eko palypse <ekopalypse at gmail.com> wrote:
>>> 
>>> Thank you for your suggestion. I will give it a try.
>>> 
>>>> What is the "stuck" thread doing? waiting for a lock?
>>> 
>>> No, it should open a dialog created with DialogBoxIndirectParamW
>>> <
>> https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-dialogboxindirectparamw
>>> 
>> 
>> I assume you are a C++ developer and can look at the stack of the thread.
>> What is the thread doing? Is it in python code? Is it in windows code?
>> 
>> Barry
>> 
>>> .
>>> 
>>> Eren
>>> 
>>>> Am Mi., 15. Apr. 2020 um 20:12 Uhr schrieb Barry Scott <
>>>> barry at barrys-emacs.org>:
>>>> 
>>>> 
>>>> 
>>>>>> On 15 Apr 2020, at 13:30, Eko palypse <ekopalypse at gmail.com> wrote:
>>>>> 
>>>>> Hi everyone,
>>>>> 
>>>>> the following happens on Windows7 x64 and Python37 x64
>>>>> 
>>>>> I have a plugin DLL for a C++ application in which Python37 is
>> embedded.
>>>>> The plugin itself works, except when I want to use the threading
>> module.
>>>>> 
>>>>> If I start a Python script in my plugin which uses the threading module
>>>>> I can verify via ProcessExplorer that the thread is started,
>>>>> but it doesn't do anything (??) and the c++ application doesn't really
>>>> do anything anymore either.
>>>>> 
>>>>> Only when I stop the C++ Applikation, the thread becomes active for a
>>>> short time.
>>>>> Verified with logging module over time print-outs.
>>>>> 
>>>>> Apparently I did not understand everything about threads and embedded
>>>> python.
>>>>> 
>>>>> Any idea what I'm doing wrong?
>>>> 
>>>> This is what I typically do.
>>>> 
>>>> Make sure that you have installed the Python debug files.
>>>> Now you can use the visual C++ debugger to attach to the process and
>>>> look at what the threads are doing.
>>>> 
>>>> I always have the python source code on hand to read as well.
>>>> 
>>>> This should give you a clue.
>>>> 
>>>> What is the "stuck" thread doing? waiting for a lock?
>>>> 
>>>> Barry
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> The whole thing is initialized by the DllMain routine.
>>>>> 
>>>>> 
>>>>> BOOL APIENTRY DllMain( HANDLE hModule,
>>>>>                     DWORD  reasonForCall,
>>>>>                     LPVOID /* lpReserved */ )
>>>>> {
>>>>>  switch ( reasonForCall )
>>>>>  {
>>>>>      case DLL_PROCESS_ATTACH:
>>>>>          if (!Py_IsInitialized())
>>>>>          {
>>>>>              PyImport_AppendInittab("Npp", &PyInit_Npp);
>>>>>              Py_InitializeEx(0);
>>>>>              PyEval_InitThreads();  //<- this shouldn't be needed as I
>>>> understand that it is called by Py_InitializeEx anyway
>>>>>          }
>>>>>          PyImport_ImportModule("Npp");
>>>>>          break;
>>>>>      case DLL_PROCESS_DETACH:
>>>>>          Py_Finalize();
>>>>>          break;
>>>>> 
>>>>>      case DLL_THREAD_ATTACH:
>>>>>          break;
>>>>> 
>>>>>      case DLL_THREAD_DETACH:
>>>>>          break;
>>>>>  }
>>>>> 
>>>>>  return TRUE;
>>>>> }
>>>>> 
>>>>> and the code in the plugin which executes the python scripts is this
>>>>> 
>>>>> cdef void run_code():
>>>>>  try:
>>>>>      global_dict = globals()
>>>>>      if '__name__' not in global_dict or global_dict['__name__'] !=
>>>> '__main__':
>>>>>          global_dict.update({"__name__": "__main__",})
>>>>>      exec(compile(editor.getText(), '<string>', 'exec'), global_dict)
>>>>> 
>>>>>  except Exception:
>>>>>      MessageBoxW(nppData._nppHandle,
>>>>>                  traceback.format_exc(),
>>>>>                  'RUN CODE EXCEPTION',
>>>>>                  0)
>>>>> 
>>>>> I don't know if this is important, but the DLL is generated by Cython.
>>>>> 
>>>>> Thank you for reading and stay healthy
>>>>> 
>>>>> Eren
>>>>> --
>>>>> https://mail.python.org/mailman/listinfo/python-list
>>>>> 
>>>> 
>>>> 
>>> --
>>> https://mail.python.org/mailman/listinfo/python-list
>>> 
>> 
>> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list