Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date
All threads index page 3

Qt-interest Archive, December 2007
Race conditions on QTextDocument


Message 1 in thread

I'm using QTextCursor and QTextBlock classes to concurrently modify the 
same QTextDocument in different threads. I'm very worried about my 
setup, because I'm missing basic information about how synchronization 
should work for concurrent access to a QTextDocument. For instance I do 
have a GUI thread, which likes to cut off some text, which is just 
currently processed by a background thread using a QTextCursor. What 
happens to this QTextCursor object? Are readers locked out, while 
someone is writing (and vise-versa)? And if so, when does a read 
operation start -- at construction time of a QTextCursor?

Thanks in advance,
Frank.

--
 [ signature omitted ] 

Message 2 in thread

Frank Mertens wrote:
> I'm using QTextCursor and QTextBlock classes to concurrently modify 
> the same QTextDocument in different threads. I'm very worried about my 
> setup, because I'm missing basic information about how synchronization 
> should work for concurrent access to a QTextDocument. For instance I 
> do have a GUI thread, which likes to cut off some text, which is just 
> currently processed by a background thread using a QTextCursor. What 
> happens to this QTextCursor object? Are readers locked out, while 
> someone is writing (and vise-versa)? And if so, when does a read 
> operation start -- at construction time of a QTextCursor?
>
> Thanks in advance,
> Frank.
>
> -- 
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with 
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
OK, figured out, that QTextDocument has no undocumented internal 
synchronization I would need to worry about (nice to have the code 
OpenSource;).  Also simply forget about how to lock up the GUI thread 
after being some months out of Qt coding. Nice to have this signal-slots 
work across threads by the means of the event loops -- so it's quite 
obvious how to lock the GUI thread in an ordered way.

Cheers, Frank.

--
 [ signature omitted ]