On terça-feira, 14 de fevereiro de 2012 17.51.33, shane.kea...@accenture.com
wrote:
> When using the low level (QTcpSocket) API, you are dealing with a stream.
> Intuitively, you would expect the stream applies flow control and rate
> limiting by itself. If using native apis (either synchronous or
ect: Re: [Development] Default enabling inbound flow control on
> sockets
>
> As you said yourself, there's a huge potential for regressions here,
> especially with a limit as low as 64k. So I am unsure whether we should
> do this at all.
>
> We could apply a high buffer size,
On sexta-feira, 10 de fevereiro de 2012 19.25.04, shane.kea...@accenture.com
wrote:
> We could change the default read buffer size from 0 (unbounded) to a
> sensible default value e.g. 64k (to be benchmarked) Applications wanting
> the old behaviour could explicitly call setReadBufferSize(0) Applic
On 02/13/2012 12:33 PM, ext marius.storm-ol...@nokia.com wrote:
> ^shrug^ but I rather not have applications start failing at random due
> to a failure to have a new limit.
..handle a new limit.
--
.marius
___
Development mailing list
Development@qt-pr
On Monday 13 February 2012 18:33:51 marius.storm-ol...@nokia.com wrote:
> On 02/13/2012 08:10 AM, ext shane.kea...@accenture.com wrote:
> >> Not sure. Is it a big problem? Or is it better to just continue as
> >> is, and let the applications that do have a problem set it to
> >> something reasonabl
On 02/13/2012 08:10 AM, ext shane.kea...@accenture.com wrote:
>> Not sure. Is it a big problem? Or is it better to just continue as
>> is, and let the applications that do have a problem set it to
>> something reasonable to them instead?
>>
>> I'd probably suggest that we instead improve the output
>
> Not sure. Is it a big problem? Or is it better to just continue as is,
> and let the applications that do have a problem set it to something
> reasonable to them instead?
>
> I'd probably suggest that we instead improve the output on that worst
> case failure to help devs fix the problems in th
ore they are in the best position to decide if they need write flow
control or not
-Original Message-
From: andrew.stanley-jo...@nokia.com [mailto:andrew.stanley-jo...@nokia.com]
Sent: 11 February 2012 11:36
To: Kearns, Shane
Subject: Re: [Development] Default enabling inbound flow control
On Friday 10 February 2012 19:25:04 shane.kea...@accenture.com wrote:
> The same change would be required at the QNetworkAccessManager level, as
> there is no point applying flow control at the socket and having unbounded
> memory allocations in the QNetworkReply.
I think it might make sense to im
> From: "shane.kea...@accenture.com"
>T he current default behaviour of Qt sockets is that they allocate an
>unbounded
> amount of memory if the application is not reading all data from the socket
> but
> the event loop is running.
> In the worst case, this causes memory allocation failure res
The current default behaviour of Qt sockets is that they allocate an unbounded
amount of memory if the application is not reading all data from the socket but
the event loop is running.
In the worst case, this causes memory allocation failure resulting in a crash
or app exit due to bad_alloc exc
11 matches
Mail list logo
