On quinta-feira, 23 de janeiro de 2014 10:23:51, André Somers wrote:
> > http://qt-project.org/doc/qt-5/qmutex.html#RecursionMode-enum
>
> If I understand it correctly, the slow mode Thiago was telling about is
> the one that provides the behavior that Philipp was asking about, right?
It is. I
Yes it seems so. Maybe that's why we still not use it Qt5.
On Thu, Jan 23, 2014 at 10:23 AM, André Somers wrote:
> Bo Thorsen schreef op 23-1-2014 9:39:
> > http://qt-project.org/doc/qt-5/qmutex.html#RecursionMode-enum
> If I understand it correctly, the slow mode Thiago was telling about is
> t
Bo Thorsen schreef op 23-1-2014 9:39:
> http://qt-project.org/doc/qt-5/qmutex.html#RecursionMode-enum
If I understand it correctly, the slow mode Thiago was telling about is
the one that provides the behavior that Philipp was asking about, right?
André
>
> Den 23-01-2014 09:24, Philipp Kursawe sk
http://qt-project.org/doc/qt-5/qmutex.html#RecursionMode-enum
Den 23-01-2014 09:24, Philipp Kursawe skrev:
> To be re-entrant from the same thread. We have the case that functions
> running in the same thread can each ask for the DB connection. That
> should still be allowed.
>
>
> On Thu, Jan 23,
To be re-entrant from the same thread. We have the case that functions
running in the same thread can each ask for the DB connection. That should
still be allowed.
On Thu, Jan 23, 2014 at 8:46 AM, Thiago Macieira
wrote:
> On quinta-feira, 23 de janeiro de 2014 05:54:36, Philipp Kursawe wrote:
>
On quinta-feira, 23 de janeiro de 2014 05:54:36, Philipp Kursawe wrote:
> Does it support the behaviour of std::recursive_mutex?
What behaviour, in specific?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description
Ah that explains it! Thanks for the benchmarks. We only tested it with the
old 4.8 implementation and decided to go with std::mutex instead. We might
check out QMutex again!
Does it support the behaviour of std::recursive_mutex?
On Wed, Jan 22, 2014 at 11:16 PM, Thiago Macieira wrote:
> On quar
On quarta-feira, 22 de janeiro de 2014 22:01:39, Philipp Kursawe wrote:
> sorry got that mixed up. Qt uses Events under Windows (was that changed in
> Qt5?), which is still not as efficient as CriticalSections.
Yes, QMutex got a large rewrite in Qt 5.
I'd like to see your benchmarks. This is what
sorry got that mixed up. Qt uses Events under Windows (was that changed in
Qt5?), which is still not as efficient as CriticalSections.
On Wed, Jan 22, 2014 at 5:11 PM, Thiago Macieira
wrote:
> On quarta-feira, 22 de janeiro de 2014 16:52:22, Philipp Kursawe wrote:
> > The Win32 implementation us
On quarta-feira, 22 de janeiro de 2014 16:52:22, Philipp Kursawe wrote:
> The Win32 implementation uses a mutex, which is used for inter-process
> sync. Inside a process its a waste. Better use CriticalSection, its a
> kernel object and several times faster then a mutex on Win32.
I'm sorry, but th
The Win32 implementation uses a mutex, which is used for inter-process
sync. Inside a process its a waste. Better use CriticalSection, its a
kernel object and several times faster then a mutex on Win32.
On Wed, Jan 22, 2014 at 4:45 PM, Thiago Macieira
wrote:
> On quarta-feira, 22 de janeiro de 2
On quarta-feira, 22 de janeiro de 2014 18:48:53, Soroush Rabiei wrote:
> A connection can only be used from within the thread that created it.
> Moving connections between threads or creating queries from a different
> thread is not supported.
> My question is how can I make connections between UI
On quarta-feira, 22 de janeiro de 2014 16:39:24, Philipp Kursawe wrote:
> Your database class uses a std::recursive_mutex (not the Qt mutex, its a
> resource waster!)
Do you have any numbers? QMutex is very small and optimised (on Linux).
QWaitCondition suffers because QMutex is so small.
--
Thi
Your database class uses a std::recursive_mutex (not the Qt mutex, its a
resource waster!) to synchronize access to the database.
Then in the method that returns a new shared pointer of QSqlDatabase you
use a std::lock_guard with that mutex to allow only one thread to use the
DB. I usually also ass
Hi
I'm writing a data-intensive application which must wait for large chunks
of data from a remote database, sometimes about 10 seconds. So I want to
keep UI in main thread (which one is running event loop) and move all data
operations to other threads. I can see how to connect signals/slots from
15 matches
Mail list logo
