>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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
