xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Opened 2 years ago

Closed 2 years ago

Last modified 8 months ago

#2448 closed defect (fixed)

win32 builds need the gtk main loop early

Reported by: totaamwin32 Owned by: totaamwin32
Priority: major Milestone: 4.0
Component: client Version: 3.0.x
Keywords: Cc:

Description

This manifests itself as a slow system / hang: Xpra 3.0 Windows very slow ssh login.

That's because when we call the dialog subprocess, the main loop is not running yet - and something apparently needs it.

The patch attached fixes things, but forces us to run the gtk main loop then exit it, before running it again.
It would be better to figure out what needs the main loop, and delay it.

Attachments (3)

temporary-main-loop.patch (1.9 KB) - added by totaamwin32 2 years ago.
possible fix
connect-after-mainloop.patch (2.1 KB) - added by totaamwin32 2 years ago.
better solution - work in progress
connect-after-mainloop-v2.patch (13.9 KB) - added by Antoine Martin 2 years ago.
updated patch

Download all attachments as: .zip

Change History (8)

Changed 2 years ago by totaamwin32

Attachment: temporary-main-loop.patch added

possible fix

comment:1 Changed 2 years ago by totaamwin32

Owner: changed from Antoine Martin to totaamwin32
Status: newassigned

Turns out that simply calling from gi.repository import Gdk seems to have some serious side effects.
Unfortunately, we can't easily delay that import as it is used everywhere.

So r24150 applies the patch above.
Since we're now running a main loop, we could even get rid of the subprocess.

A cleaner solution would be to run the real main loop before calling setup_connection.

Changed 2 years ago by totaamwin32

better solution - work in progress

comment:2 Changed 2 years ago by totaamwin32

The patch above is a better solution: we only setup the connection after the main loop has started.

To be merged, we will need to update all the other client classes (ie: WaitForDisconnectXpraClient, RequestStartClient etc) to do the same thing.

Changed 2 years ago by Antoine Martin

updated patch

comment:3 Changed 2 years ago by Antoine Martin

Merged in r24171.

Still TODO: revert to running the dialog in-process, which will make it more reliable for handling non-ascii characters.

comment:4 Changed 2 years ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

SSH dialogs now run in-process: r24225.

See also #2549.

Last edited 15 months ago by Antoine Martin (previous) (diff)

comment:5 Changed 8 months ago by migration script

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2448

Note: See TracTickets for help on using tickets.