[Development] [QIODevice]How to correctly treat/understand of the documentation?

[Denis Shienkov]

Hi Carlos,

 > Disclaimer. I don't work for Digia and I have never worked for Digia. 
I did work for Trolltech and Nokia though.

Ahh, clear. Thx.

 > I think you are starting from the wrong end. The question is not if 
you should support one mode of operation or the other, that needs to be 
analyzed case by case. IMHO you should implement both modes of operation 
and let the user decide which one to use by specifying the right flags 
at open time.

Yes, I agree. In the future we will add Unbuffered mode, but that isn't 
the in this question.
Because I talk about Buffered mode only.

 > I think I disagree with that statement. This is not a very important 
part of the project, it is an implementation detail.

No. These details cause rough disputes between members of team. :)

Thus it is necessary accurately and to be defined specifically, what 
behavior we expect. Because implementation and behavior depends on it. 
And other methods: write(), flush(), waitForXX(), bytesWritten() signal 
and etc, also depends on it, I.e. everything is interdependently.

Also I don't agree that the buffered mode isn't necessary. The buffered 
mode is obliged to be, and it is preferred way, especially, for the 
serial port. Since differently, is possible loss the data, related with 
the limited FIFO sizes (which can be overflowed) and other nuances. :)

PS: But it all is offtop...

BR,
Denis




18.04.2014 21:02, Carlos Duclos ?????:
>
> >Hi.
> >
>
> Hi again,
>
> Disclaimer. I don't work for Digia and I have never worked for Digia. 
> I did work for Trolltech and Nokia though.
>
> >I once again fluently look source codes of Qt and I see that the only one
> >I/O class which supports a buffered mode is QTcpSocket (i.e.
> >QAbstractSocket in buffered mode); in which is used the "deferred" 
> writing
> >for data transfer.
> >
> >Thus, whether can I take such behavior (with "deferred" writing) as a 
> basis
> >for implementation of I/O in QtSerialPort where only buffered mode is 
> used
> >(as in QTcpSocket) ?
> >
> >Because I don't see other precedents and examples which to take as a 
> >basis.
> >
> >What do you think?
> >
>
> I think you are starting from the wrong end. The question is not if 
> you should support one mode of operation or the other, that needs to 
> be analyzed case by case. IMHO you should implement both modes of 
> operation and let the user decide which one to use by specifying the 
> right flags at open time.
>
> >PS: As it is very important part of the project.
>
> I think I disagree with that statement. This is not a very important 
> part of the project, it is an implementation detail. Let's talk about 
> serial port support and what is the goal of the project. If I 
> understand correctly what you want to do is to provide a class that 
> can be used for interacting with a serial port and that can be used by 
> other Qt classes seamlessly. If that is not the goal of the project, 
> please explain what is the goal of the project because we might be 
> talking about different things.
>
> That being said, a serial port is not something magical, it is 
> something that is used in many situations. Many operating systems 
> provide simple API's to read and write data from and to them. Settings 
> (speed, parity, etc) are usually specified by special calls, such as 
> ioctl. The OS will most likely already provide transparent buffering 
> both for reading and writing, therefore in the strictest sense you 
> shouldn't need to implement buffering at all. However, there are 
> situations when you will want to "pretend" that you wrote to the 
> serial port, even if the data is still in your buffer. Let's focus on 
> write(2). If you need to operate asynchronously, you need to wait 
> until the OS tells you that is ok to write and possibly only write the 
> amount of data that the OS tells you that is ok to write. In those 
> cases, you might want your data structure to have a write method that 
> puts the data into a buffer, and then request the OS to let you know 
> when it is ok for you to write the data. From the user point of view, 
> the data was written after calling QSerialPort::write(...), even 
> though the data is still somewhere in QSerialPort. Once QSerialPort 
> gets the ok from the OS (probably by waiting until the EventLoop gets 
> the right signal back from the OS), you can start the real transfer of 
> the data to the "physical" device. Notice that I wrote "physical" 
> because the OS might do the same thing again and only buffer the data 
> until the hardware says that is ok to send the data.
>
> In other situations it might be better for the user if the data is 
> written immediately to the underlying device, even if this might 
> introduce a wait. As explained, most likely the system will buffer the 
> data and usually there are no "flush" operations on such devices 
> (flush makes sense for file systems but little sense for devices that 
> might freeze the system for ages).
>
> If you are using a system where the OS does not provide such 
> abstractions and you need to talk directly to the UART then the 
> picture might be different, but I doubt that you will be using Qt if 
> that was the case.
>
> Cheers!
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140419/cad07375/attachment.html>