mbahar94 / qextserialport

Automatically exported from code.google.com/p/qextserialport
Other
0 stars 0 forks source link

bool QextSerialPort::waitForReadyRead(int msecs) #111

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Hi,

First, many thanks for the useful code!
The aforementioned function is marked as TODO.
I need a "Polling" Port running in separate thread.
The "Eventdriven" is not working for me for two reasons:
- In a separate thread its hard to use slots.
- In the GUI thread, it freezes my GUI during the readout.

Therfore my solution was to implement the waitForReadyRead and use it with the 
'Pooling' port in a separate thread.
The implementation of the waitForReadyRead which works fine for me is the 
following:

bool QextSerialPort::waitForReadyRead(int msecs)
{
    //@todo implement
    SetCommMask(Win_Handle, EV_RXCHAR);

    DWORD dwEventMask;
    if(WaitCommEvent(Win_Handle, &dwEventMask, NULL))
    {
        return true;
    }else
        return false;

}

--
Regards,
Dzmitry Stsepankou

Original issue reported on code.google.com by dstep...@gmail.com on 16 Nov 2011 at 8:43

GoogleCodeExporter commented 9 years ago
Hello Dzmitry,

I cannot figure out what is problem you come with. 
IMO, 
- Generally, Signals and slots should work very well in a separate thread.
- "Eventdriven" mode will not freeze any thread unless you called waitXXX.

And in "Poling" mode, wartForReadyRead() should be useless, In my option, 
simply call read() will get the same blocking effect.

Original comment by dbzhang...@gmail.com on 17 Nov 2011 at 4:50

GoogleCodeExporter commented 9 years ago
Hi,

Please see my answers:

" Generally, Signals and slots should work very well in a separate thread."

> Signals yes, but with the slots there are some problems, see here for ex:
http://developer.qt.nokia.com/wiki/Threads_Events_QObjects
See the section "DOs and DON'Ts". And for me it didn't work somehow as well.

""Eventdriven" mode will not freeze any thread unless you called waitXXX."

>My software constantly reading data from the port and displaing it on the 
graph,
And I have experienced the freezing of the mouse in the graph each time the 
data is reading out from the port (i.e. slot onReadyRead execution). I'm not 
using any "wait" there. Note, that in this case the QExtSerialPort object lives 
in the GUI thread.

This problem is perfectly solved when I move the QExtSerialPort object into a 
separate thread, then I had a problem with the slots in "EventDriven" mode, 
therefore I've switched to "Pooling".

"And in "Poling" mode, wartForReadyRead() should be useless, In my option, 
simply call read() will get the same blocking effect."

> You are right! I just didn't know that. 
Thanks!

Original comment by dstep...@gmail.com on 17 Nov 2011 at 8:48

GoogleCodeExporter commented 9 years ago
yeap, this is a very good article, I have read it. It pointed out many traps 
when using QThread.

However, Signals and slots still works well with QThread. If you not familar 
with it yet, the manual may be useful for you: 
http://doc.qt.nokia.com/4.8/thread-basics.html

If "Eventdriven" mode really freeze your thread, it is most likely to be an bug 
in QextSerialPort. 

Original comment by dbzhang...@gmail.com on 17 Nov 2011 at 12:50

GoogleCodeExporter commented 9 years ago

Original comment by dbzhang...@gmail.com on 16 Mar 2012 at 8:59