On Tuesday 09 August 2011 17:19:49 Olivier Goffart wrote:
> The proper thing to use here is a QWaitCondition
Which is easy to write racy code with (if B calls wake() before A calls
wait(), A missed the notification for good and it will sleep forever), so I
usually prefer a QSemaphore (which uses
On Dimarts 09 Agost 2011 14:57:06 David Faure wrote:
> > I just tried a test calling that function with 0 as timeout (so it always
> > timeouts) and sometimes it waits until 1 second so it is quite clear it
> > is waiting for the thread.
>
> Yes, Thiago explained to me the notion of cancellation p
> I just tried a test calling that function with 0 as timeout (so it always
> timeouts) and sometimes it waits until 1 second so it is quite clear it is
> waiting for the thread.
Yes, Thiago explained to me the notion of cancellation points, and proved me
wrong. And since anyway terminate is a ba
On Tuesday 09 August 2011 12:59:49 Thomas Zander wrote:
> On Monday 08 August 2011 16.28.43 Dawit A wrote:
> > > Apologies for still not getting it..> You stated you wanted to have
> > > a
> > > timeout to avoid a blocking UI, which as
> > > far as I understand you would also avoid if you don't cre
On Dimarts 09 Agost 2011 12:14:53 Thomas Zander wrote:
> On Tuesday 09 August 2011 12.59.49 Thomas Zander wrote:
> > Another solution for using a timeout can be something like the
> > attached version (I didn't even try to compile it, maybe the helper
> > object has to be
> > moved to a _p.h file t
> On Aug. 8, 2011, 1:53 p.m., David Faure wrote:
> >
>
> David Faure wrote:
> (Sorry, flaky wifi lost the comment)
>
> I am very much against a nested event loop (QEventLoop::exec), it's a
> well-known fact nowadays that it creates unexpected re-entrancy and crashes.
>
> A
On Tuesday 09 August 2011 12.59.49 Thomas Zander wrote:
> Another solution for using a timeout can be something like the
> attached version (I didn't even try to compile it, maybe the helper object
> has to be
> moved to a _p.h file to get moc to run on it..)
Oh, and the mutex has to be made recu
On Monday 08 August 2011 16.28.43 Dawit A wrote:
> > Apologies for still not getting it..> You stated you wanted to have a
> > timeout to avoid a blocking UI, which as
> > far as I understand you would also avoid if you don't create a new
> > method that never blocks in the first place.
>
> The uri
On Tuesday, 9 de August de 2011 00:33:46 David Faure wrote:
> No no, I call wait after *terminate* ! Terminate is "almost instant
> termination", it kills the thread. So this does not wait for the DNS lookup
> to be finished, it only waits for terminate to call the cleanup callback,
> which should
(I reply to the list only, as it is not related to the request itself)
> And no, we definitely want no nested event loop. Anything else, but
> not that.
I agree 100%. When you see things like the same modal messagebox popping
up twice (so one is visible, and another one appears called from the
> On Aug. 8, 2011, 1:53 p.m., David Faure wrote:
> >
>
> David Faure wrote:
> (Sorry, flaky wifi lost the comment)
>
> I am very much against a nested event loop (QEventLoop::exec), it's a
> well-known fact nowadays that it creates unexpected re-entrancy and crashes.
>
> A
On Monday, 8 de August de 2011 15:28:45 Dawit A wrote:
> Yes. The uri filter plugins that are the primary users of this new
> function require a synchronous function call or they would all have to
> implement this syncing part individually for themselves.
Then let them do it.
--
Thiago Macieira
On Mon, Aug 8, 2011 at 3:56 PM, Thomas Zander wrote:
> On Monday 08 August 2011 21.28.45 Dawit A wrote:
>> On Mon, Aug 8, 2011 at 3:20 PM, Thomas Zander wrote:
>> > On Monday 08 August 2011 21.02.02 Dawit A wrote:
>> >> On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander wrote:
>> >> > On Monday 08 Au
On Monday 08 August 2011 21.28.45 Dawit A wrote:
> On Mon, Aug 8, 2011 at 3:20 PM, Thomas Zander wrote:
> > On Monday 08 August 2011 21.02.02 Dawit A wrote:
> >> On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander wrote:
> >> > On Monday 08 August 2011 18.35.13 Dawit A wrote:
> >> >> #2. The original f
On Mon, Aug 8, 2011 at 3:20 PM, Thomas Zander wrote:
> On Monday 08 August 2011 21.02.02 Dawit A wrote:
>> On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander wrote:
>> > On Monday 08 August 2011 18.35.13 Dawit A wrote:
>> >> #2. The original functions in this class were non-blocking. It is only
>> >>
On Monday 08 August 2011 21.02.02 Dawit A wrote:
> On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander wrote:
> > On Monday 08 August 2011 18.35.13 Dawit A wrote:
> >> #2. The original functions in this class were non-blocking. It is only
> >> the new function I added that is a blocking call. And that i
> On Aug. 8, 2011, 1:53 p.m., David Faure wrote:
> >
>
> David Faure wrote:
> (Sorry, flaky wifi lost the comment)
>
> I am very much against a nested event loop (QEventLoop::exec), it's a
> well-known fact nowadays that it creates unexpected re-entrancy and crashes.
>
> A
On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander wrote:
> On Monday 08 August 2011 18.35.13 Dawit A wrote:
>> #2. The original functions in this class were non-blocking. It is only
>> the new function I added that is a blocking call. And that is required
>> because of the need for a timeout when doin
On Monday 08 August 2011 18.35.13 Dawit A wrote:
> #2. The original functions in this class were non-blocking. It is only
> the new function I added that is a blocking call. And that is required
> because of the need for a timeout when doing name lookups from the
> urifilter plugins. Thos plugins p
> On Aug. 8, 2011, 1:53 p.m., David Faure wrote:
> >
>
> David Faure wrote:
> (Sorry, flaky wifi lost the comment)
>
> I am very much against a nested event loop (QEventLoop::exec), it's a
> well-known fact nowadays that it creates unexpected re-entrancy and crashes.
>
> A
On Mon, Aug 8, 2011 at 11:25 AM, Thiago Macieira wrote:
> On Monday, 8 de August de 2011 14:25:13 David Faure wrote:
>> And since I just fixed the crash (missing wait() after terminate(), see
>> commit log), I don't think we need this change. However reusing threads
>> might be a good idea (separa
On Monday, 8 de August de 2011 14:25:13 David Faure wrote:
> And since I just fixed the crash (missing wait() after terminate(), see
> commit log), I don't think we need this change. However reusing threads
> might be a good idea (separate issue).
This could probably use a redesign. If this class
> On Aug. 8, 2011, 1:53 p.m., David Faure wrote:
> >
(Sorry, flaky wifi lost the comment)
I am very much against a nested event loop (QEventLoop::exec), it's a
well-known fact nowadays that it creates unexpected re-entrancy and crashes.
And since I just fixed the crash (missing wait() after t
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102238/#review5499
---
- David
On Aug. 7, 2011, 4:07 a.m., Dawit Alemayehu wrote:
>
> On Aug. 7, 2011, 7:59 a.m., Thiago Macieira wrote:
> > Looks good, but I have a question on the cache: what are its features?
> >
> > Is it permanent (saved to disk)? Is it shared among applications? Not
> > shared among ioslaves through one application, I really mean across
> > applications
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102238/#review5472
---
Looks good, but I have a question on the cache: what are its fea
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102238/#review5467
---
>From the code POV seems fine to me, will try it later when some
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102238/
---
Review request for kdelibs.
Summary
---
This patch replaces the creat
28 matches
Mail list logo
