bugGNU Octave - Bugs: bug #40343, Suggestion: Add XInitThreads()...

 
 

bug #40343: Suggestion: Add XInitThreads() call before starting the QT based GUI.

Submitter:  None
Submitted:  Tue 22 Oct 2013 03:17:46 AM UTC
   
 
Category:  GUI Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  None Assigned to:  None
Originator Name:  Mario Kleiner Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * dev
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 26 May 2022 08:27:40 PM UTC, comment #2: 

Since Qt5, the attribute Qt::AA_X11InitThreads is obsolete and has no effect. Unfortunately, I haven't found any hint on the reason for this (maybe it is not necessary anymore?).

Since generally calling XInitTread might degrade the performance, I suggest to close this bug with "Wont Fix".

Torsten Lilge <ttl>
Group Member
Tue 22 Oct 2013 04:27:02 AM UTC, comment #1: 

Sounds easy enough to do, although a google search turns up a lot of questions about the potential performance hit from doing this unconditionally. So while it may help greatly for the case you have in mind, it may hurt the GUI in general and everyone else who doesn't need this feature. I don't know, I haven't tested it.

For reference, XInitThreads could be called directly, or, if we ever require Qt >= 4.8 at some point (we currently work with >= 4.6), Qt now has an option to initialize this for you:


QApplication::setAttribute(Qt::AA_X11InitThreads);


but again, only in Qt 4.8 or higher. This call must be done before constructing the QApplication object.

Mike Miller <mtmiller>
Group Member
Tue 22 Oct 2013 03:17:46 AM UTC, original submission:  

This is a mixture of proposal and request. It would be a good idea to add a call to XInitThreads() in octave's GUI startup function before the QT based GUI or other XLib based functionality is initialized.

XInitThreads() switches XLib into thread-safe mode, using proper internal locking, so that XLib functions can be called concurrently from different threads without mysterious crashes or hangs. This would be beneficial for 3rd party toolboxes/code, which might use XLib internally inside mex/oct files. It could also help avoiding some multi-threading bugs iff the QT based GUI does XLib calls to update widgets from different threads - i didn't check if it actually does that.

In the past, my own open-source toolkit Psychtoolbox called XInitThreads() internally when its mex files got loaded into octave, because it performs XLib calls from different threads, but with octave's GUI this is no longer an option, because XInitThreads() must be called before any other XLib function in a process, and as octave's GUI uses QT and QT will call XLib functions during GUI startup, my mex files will be too late to the party if they try to call XInitThreads() after the octave session is already running.

I resolved this problem by introducing my own locking around XLib calls, but other 3rd party octave extensions might run into similar problems or regressions on Octave 3.7+ with GUI enabled.

thanks,
-mario

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-10-22 mtmiller Severity3 - Normal 1 - Wish
        Item GroupOther Feature Request

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code