readch and ctrl+c

[copse]

I've got a script that loops on READCH('serial') but it does not respond to Ctrl+c. Whether the default handling or a custom SIGNAL handler.

My assumption is that READCH('serial') is a blocking call and it prevents the arexx signal handler from being run.

Sound correct? Is there a way to get around this?

I tried polling EOF('serial') before doing a READCH, but it always returns 0 even if nothing has been sent.

[daxb]

Can you show the script? What is the meaning of "READCH('serial')"? 'serial' can be everything that is opened before. So is it SER: device or what? A normal READCH() from a file will break by a CTRL+C but I do not know if read from SER: is different.

[thomas]

Originally Posted by daxb

A normal READCH() from a file will break by a CTRL+C

No, it won't. READCH will indeed block until the requested character is received. Only then the script can check for Ctrl-C and stop if need be.

dos.library has a WaitForChar function for this purpose which will return after a given amount of time if no character is received. But I don't know if any ARexx function utilises it.

[Thomas Richter]

The port-handler from 3.2 also has a non-blocking option for SER:. In such a case, an attempt to read returns 0 bytes. That is the option NOWAIT in the path.

[daxb]

Ok, I've only tested the working condition of READCH(). I guess a read from a file will always work.

So how can READCH() fail or wait for character for ever? Maybe reading from SER: means there is no EOF or similar condition (stream without any size/end information)? If so I also don't see any ARexx function that will help if nothing is returned and therefore you cannot respond to. There is SIGNAL ON IOERR but if no error is received it will not help. ARexxGuide2 has some I/O examples but if they can help?

Maybe there is an external library with such WaitForChar function but I don't know any.

[Thomas Richter]

Originally Posted by daxb

So how can READCH() fail or wait for character for ever?

See RKRM DOS:

https://github.com/thorfdbg/rkrm-dos/blob/main/dos.pdf

section 12.3.

Originally Posted by daxb

Maybe reading from SER: means there is no EOF or similar condition (stream without any size/end information)?

SER: implements a blocking read, unless you tell it not to block. See also the above reference. READCH is, unless you configure your stream carefully, not the right option.

[copse]

Originally Posted by Thomas Richter

The port-handler from 3.2 also has a non-blocking option for SER:. In such a case, an attempt to read returns 0 bytes. That is the option NOWAIT in the path.

Thanks Thomas. Good to know. I thought Arexx might have been the simplest way to play around with reading from the serial port, but it took me ages to work out that at least the version I was using was erroring because I didn't have a comment at the top and working because I put a comment there by happenstance! Crikey, I wonder how much user time that design decision wasted over the years.

If I come back to it I'll check out the port handler and upgrade to 3.2.