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
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
