Hi,
Please use https://bugreports.qt-project.org to open a new issue. It looks like
a very serious regression to me!
BogDan.
Trimis din Yahoo! Mail pe Android
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman
Thanks, looking at qatomic.h it indeed looks like Qt is doing low
level hw/compiler thread related work which is not exposed in the standard
C++ language or in posix.
I didn't expect that, my bad.
On Mon, Oct 28, 2013 at 12:58 AM, Thiago Macieira wrote:
> On segunda-feira, 28 de outubro de 2013
On 27 Oct 2013, at 12:00, development-requ...@qt-project.org wrote:
> From: Thiago Macieira
> Subject: Re: [Development] QtWebSockets: API advice #2
> Date: 27 Oct 2013 11:36:40 GMT+1
> To: development@qt-project.org
>
>
> On domingo, 27 de outubro de 2013 11:16:03, Kurt Pattyn wrote:
>> curre
On segunda-feira, 28 de outubro de 2013 00:38:51, Jiergir Ogoerg wrote:
> Probably, but then afaik it either (a) somehow can create barriers or (b)
> implements
> a broken but good enough solution like DCLP (double checked locking
> pattern),
> I couldn't figure out cause it uses Qt specific macros
By accident I sent the email to you too, sorry, gmail by default selects
both emails.
On Mon, Oct 28, 2013 at 12:38 AM, Jiergir Ogoerg wrote:
> Probably, but then afaik it either (a) somehow can create barriers or (b)
> implements
> a broken but good enough solution like DCLP (double checked loc
Probably, but then afaik it either (a) somehow can create barriers or (b)
implements
a broken but good enough solution like DCLP (double checked locking
pattern),
I couldn't figure out cause it uses Qt specific macros and functions.
On Mon, Oct 28, 2013 at 12:31 AM, Thiago Macieira wrote:
> On
On segunda-feira, 28 de outubro de 2013 00:12:36, Jiergir Ogoerg wrote:
> Yep, I know, the solution I proposed was also thread safe, but it didn't
> require a lock/unlock
> on each function call or extra memory structs around it.
Q_GLOBAL_STATIC does not lock/unlock for every access. Only for the
Yep, I know, the solution I proposed was also thread safe, but it didn't
require a lock/unlock
on each function call or extra memory structs around it.
Anyway, I stumbled across the home
path thingy as a side effect of looking into a different Qt issue (startup
time, which is
pretty much unrelated
On domingo, 27 de outubro de 2013 22:51:59, Jiergir Ogoerg wrote:
> But looking at its source code [1] and since this was a micro-optimization
> to begin with, I guess it's
> not worth bothering caching the home dir path.
Since QDir::homePath() needs to be thread-safe, you need to use
Q_GLOBAL_ST
Thanks, that looks like a nice and elegant solution.
But looking at its source code [1] and since this was a micro-optimization
to begin with, I guess it's
not worth bothering caching the home dir path.
[1]
Apparently gotta lock/unlock a mutex on each function call, plus under the
hood Q_GLOBAL_S
On Sunday 27 October 2013 04:53:41 Jiergir Ogoerg wrote:
> It looks like only the home and temp dir paths are worth caching, their
> window$ implementation is ~ 30-40 lines of code
> if counting QDir's subcalls to QFileSystemEngine.
>
> For these two QDir functions to stay one liners and lock-less
On Sun, 27 Oct 2013, Thiago Macieira escribió:
> On domingo, 27 de outubro de 2013 08:33:56, Rodolfo García Peñas wrote:
> > The flag "CFG_MULTIMEDIA" is selected twice in the configure file.
> > The -no-nultimedia option has a typo and is dup.
> >
> > Signed-off-by: Rodolfo García Peñas (kix)
>
On domingo, 27 de outubro de 2013 08:33:56, Rodolfo García Peñas wrote:
> The flag "CFG_MULTIMEDIA" is selected twice in the configure file.
> The -no-nultimedia option has a typo and is dup.
>
> Signed-off-by: Rodolfo García Peñas (kix)
Hello Rodolfo
Sorry, we cannot accept patches posted to t
On domingo, 27 de outubro de 2013 11:07:39, Kurt Pattyn wrote:
> Hi,
>
> I would like to add secure sockets support to the QWebSocket class (see
> QtWebSockets add-on at https://qt.gitorious.org/qtplayground/websockets).
> Currently, a connection is made to a web socket server, as follows:
> QWebS
On domingo, 27 de outubro de 2013 11:16:03, Kurt Pattyn wrote:
> currently the QWebSocket class (see
> https://qt.gitorious.org/qtplayground/websockets), emits the signals
> textFrameReceived() and binaryFrameReceived(). These signals are tightly
> connected with the way web sockets work. Too me, t
Hi,
currently the QWebSocket class (see
https://qt.gitorious.org/qtplayground/websockets), emits the signals
textFrameReceived() and binaryFrameReceived().
These signals are tightly connected with the way web sockets work. Too me, this
feels too ‘low level’.
Wouldn’t it be better to buffer thes
Hi,
I would like to add secure sockets support to the QWebSocket class (see
QtWebSockets add-on at https://qt.gitorious.org/qtplayground/websockets).
Currently, a connection is made to a web socket server, as follows:
QWebSocket webSocket;
webSocket.open(QUrl(“ws://someserver”));
The flag "CFG_MULTIMEDIA" is selected twice in the configure file.
The -no-nultimedia option has a typo and is dup.
Signed-off-by: Rodolfo García Peñas (kix)
---
configure | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/configure b/configure
index 256f485..e525866 100755
--
18 matches
Mail list logo
