Program hangs when I use trackPopupMenuEx about win32 HOT 7 OPEN

Hi @xafizoff can you give me a full source repro?

Also did you try with -threaded?

Thanks.

from win32.

How to reproduce

> git clone https://github.com/xafizoff/haskell-win32-example.git
> cd haskell-win32-example
> cabal new-run haskell-win32-example-exe

Environment

> cabal --version
cabal-install version 3.2.0.0
compiled using version 3.2.0.0 of the Cabal library

> ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3

from win32.

Also reproducible with Win32 v2.9.0.0. Sometimes you need to play with the cursor to freeze the program.

from win32.

That looks like it's because you're blocking the message pump. trackPopupMenuEx is a blocking foreign call since it waits till the function returns. However in that time it's posting messages back the main Window expecting it to handle them, but the main loop is blocked so Windows marks the window as unresponsive.

(Graphics.Win32.tPM_RIGHTBUTTON .|. Graphics.Win32.tPM_NONOTIFY) will tell it not to try to post messages to the Window but handle them in it's own loop, but external events can still make the Window unresponsive. i.e. focus changes.

That said I don't remember enough about these Window APIs to suggest a complete solution, my initial thought it the pump must be created on a different OS thread, or the menu. a C tutorial on how to use this should have the right approach.

from win32.

I don't know why it is blocking, probably due to Haskell RTS involvement, but similar C code works fine. So I ended up doing all GUI related stuff as a single foreign call. I just pushed it to github.

from win32.

This is almost certainly the fault of this unsafe foreign import:
https://github.com/haskell/win32/blob/master/Graphics/Win32/Menu.hsc#L426-L427

I surmise from this thread of issues that c_TrackPopupMenu is a blocking function and thus should never be foreign imported unsafely. Unsafe foreign imports keep the RTS capability running Haskell code locked while the foreign code happens.

In multi-threaded runtime all capabilities must synchronise before GC can happen and those threads will block until synchronisation happens. Since the capability doing the unsafe foreign call can't synchronise this means all threads are blocked until the unsafe foreign call returns.

This is not the only dangerous unsafe foreign import, I found this issue after someone on IRC mentioned deadlocking when they used sleep, which also does an unsafe foreign import and suffers the same problem.

The solution is to not import these unsafely. Or even better remove all unsafe foreign imports from the package except those that are 100%, definitely known to be safe (i.e. non-blocking and short running).

from win32.

Hello,

This is almost certainly the fault of this unsafe foreign import:
https://github.com/haskell/win32/blob/master/Graphics/Win32/Menu.hsc#L426-L427

hm I was sure I tried that, but most likely changed the wrong one. In any case I'll look into these again.

The solution is to not import these unsafely. Or even better remove all unsafe foreign imports from the package except those that are 100%, definitely known to be safe (i.e. non-blocking and short running).

Indeed, these UI bits were added as a mass import but clearly some slipped by.

from win32.