Read timeout BaseSequentialStream

[Jeroen3]

Hi, I'm using 2.6.x.

I noticed there are no functions to read from a SerialDriver through a BaseSequentialStream with a timeout, all read (and put for that matter) are blocking. (doc doesn't tell you)
I can see that the Serial_lld does have putt and gett stuff. But MemoryStream doesn't.
First I though I could use the Queues directly, but I can't because my use case involves thread-to-thread streams. None of those are I-lock low level drivers.

I'd like to be able to connect my thread to either an USB or an TCP MemoryStream based on what is available.

Any thoughts?

But wow, that BaseSequentialStream construction hard to follow...

[Giovanni]

Hi base streams are supposed to be without timeouts, timeouts are introduced by a subclass (channels).

I agree that it is hard to read code but it is the price to pay to do inheritance using C.

Giovanni

[Jeroen3]

Can I safely use chThdResume to break out of a chIQGetTimeout(TIME_INFINITE)?
I'd need some method to timeout on idle communication.

[Giovanni]

No, you have to use the timeout feature of chIQGetTimeout(), see that TIME_INFINITE? you may also consider chIQResetI().

Giovanni

[Jeroen3]

Onto creating custom BaseSequentialStream then. Or a copier layer...

Maybe a little * needs to be added to the doc.

#define chSequentialStreamWrite(ip, bp, n) ((ip)->vmt->write(ip, bp, n))
Sequential Stream write.
#define chSequentialStreamRead(ip, bp, n) ((ip)->vmt->read(ip, bp, n))
Sequential Stream read.
#define chSequentialStreamPut(ip, b) ((ip)->vmt->put(ip, b))
Sequential Stream blocking byte write.
#define chSequentialStreamGet(ip) ((ip)->vmt->get(ip))
Sequential Stream blocking byte read.

The above two don't say blocking, but they are if you driver is. Also, the bottom two might not be if your driver isn't.

Thanks.

[Jeroen3]

Currently, I've derived a SerialStream from a SerialDriver. Which basically is an SerialDriver without lld.
The low-side of the queue's must be read/written manually by the thread operating the rear-end using the notify callbacks.

Memstreams are weird since a write to memstreams will overwrite or skip the queues when they are full. The producer thread must wait until the consumer thread has cleared some space.
What is the point in writing to a memstream if it is truncated when tcp transmitting takes a little longer?

By the way, SerialDriver have a notable design limitation when operating through a BaseSequentialStream. When a read operation has started, the only way to resume the reading thread (in a clean way) is by a valid read operation or sdStop().

[jayalfredprufrock]

I just came across this thread while looking for clarification as to whether the BaseSequentialStream functions read and write should be blocking. The docs (in version 3 too) make it sound like it's non-blocking (and that put/get are blocking) but in the case of the serial driver over usb the read and write functions definitely block. Is this behavior implementation dependent? If so, that would be a useful footnote in the docs. If not, it should probably be noted in the docs that the read/write functions are also blocking.

My particular use case arose from a custom shell implementation I'm working on. I'm having a hard time properly handling ASCII control codes. For instance, within the OSX terminal a mouse scroll up gets treated as an up arrow control code, so the two bytes "[A" get transmitted. Without some kind of timeout mechanism or the ability to check how many unread bytes are in the BaseSequentialStream's buffer it's impossible to distinguish such a control code from actually typing the characters '[' and 'A' separately. Any ideas?

[Giovanni]

Hi,

The read and write functions are always blocking in BaseSequentialStream. The interface BaseChannel, a descendant of BaseSequentialStream, adds timeout variants can be also used in non-blocking mode (TIME_IMMEDIATE as timeout).

Giovanni

[gnif]

I just came across this thread while looking for clarification as to whether the BaseSequentialStream functions read and write should be blocking. The docs (in version 3 too) make it sound like it's non-blocking (and that put/get are blocking) but in the case of the serial driver over usb the read and write functions definitely block. Is this behavior implementation dependent? If so, that would be a useful footnote in the docs. If not, it should probably be noted in the docs that the read/write functions are also blocking.

My particular use case arose from a custom shell implementation I'm working on. I'm having a hard time properly handling ASCII control codes. For instance, within the OSX terminal a mouse scroll up gets treated as an up arrow control code, so the two bytes "[A" get transmitted. Without some kind of timeout mechanism or the ability to check how many unread bytes are in the BaseSequentialStream's buffer it's impossible to distinguish such a control code from actually typing the characters '[' and 'A' separately. Any ideas?

That is a vt100 control code, it is not specific to apple, and it will be prefixed by the escape character, which is what you need to look for. It is actually sending "\033[A"