Mailing List Archive

Re: [SPAM] Re: Console taking 100% CPU
On Tue, 2010-12-14 at 16:54 -0500, Chris Marget wrote:
> read(0, "", 8192) = 0
> select(4, [0 3], [], NULL, NULL) = 1 (in [0])
> read(0, "", 8192) = 0
> select(4, [0 3], [], NULL, NULL) = 1 (in [0])
> read(0, "", 8192) = 0

select() has seen STDIN ready to be read.
read() reads 0 bytes. This is an EOF condition.

Easy. Fix the code so that when reading from 0 if 0 bytes are read is
restores the terminal and exits.


_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: [SPAM] Re: Console taking 100% CPU [ In reply to ]
On Tue, Dec 14, 2010 at 4:59 PM, Chris Fowler
<cfowler@outpostsentinel.com> wrote:
> On Tue, 2010-12-14 at 16:54 -0500, Chris Marget wrote:
>> read(0, "", 8192)                       = 0
>> select(4, [0 3], [], NULL, NULL)        = 1 (in [0])
>> read(0, "", 8192)                       = 0
>> select(4, [0 3], [], NULL, NULL)        = 1 (in [0])
>> read(0, "", 8192)                       = 0
>
> select() has seen STDIN ready to be read.
> read() reads 0 bytes.  This is an EOF condition.
>
> Easy.  Fix the code so that when reading from 0 if 0 bytes are read is
> restores the terminal and exits.

I've added two lines here. Seems to do what I need. Am I on the right track?

static int screwy = 0;
<snip>
/* anything from stdin? */
if (FD_ISSET(0, &rmask)) {
if ((nc = read(0, acMesg, sizeof(acMesg))) <= 0) {
if ( nc == 0 ) fprintf(stderr, "gotcha!\n"); // added by chris m
if ( nc == 0 ) break; // added by chris m
if (screwy)
break;
else {
FD_SET(0, &rinit);
continue;
}
}


Thanks very much!

/chris

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: [SPAM] Re: Console taking 100% CPU [ In reply to ]
On Tue, Dec 14, 2010 at 05:15:05PM -0500, Chris Marget wrote:
>
> I've added two lines here. Seems to do what I need. Am I on the right track?

Not really. There is nothing "screwy" about read returning 0; it just means
end-of-file. And negative values other than -1 are not allowed by POSIX.
Bearing that in mind, a better structure for the code would be:

if (FD_ISSET(STDIN_FILENO, &rmask)) {
nc = read(0, acMesg, sizeof(acMesg);
switch (nc) {
case -1:
/* handle error */
break;
case 0:
/* handle end-of-file */
break;
default:
/* do whatever is usual;
continue;
}
break; /* THIS one gets you out of the outer loop.
Strategic use of 'goto' may make the code more clear. */
}

Generally speaking testing particular individual file descriptors against
the returned descriptor set is a sign of questionable program structure,
though. Usually, programs calling select should loop over all the returned
descriptors, handling each in turn.

Thor
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: [SPAM] Re: [SPAM] Re: Console taking 100% CPU [ In reply to ]
On Tue, 2010-12-14 at 17:24 -0500, Thor Simon wrote:
> There is nothing "screwy" about read returning 0; it just means
> end-of-file

Years back we had a problem with Java NIO not understanding that read of
0 = EOF. If the user terminated the console client (written in Java as
a we applet) gracefully then everything was fine. The problem we
experienced happened when the network went down or the connection was
lost. Once the TCP keep alive failed then NIO would go into this nasty
select(), read(), select() loop just like his strace output. Problem
was that the Java programmer was not a POSIX programmer and the strace
output that I gave him showing this was totally Greek. He did
everything "by the NIO book". In the end I "fired" that code and
replaced it with a Perl version. I still use the console Java applet we
wrote but the web proxy is now in Perl. The proxy is required because
Java applet security will only let you connect to the originating host.
Conserver is running on many embedded devices so the proxy's job is to
bridge communications from the web applet and the conserver program on
the device in the field. It is little more than a select() loop on a
bunch of FD's. It does update the database and log the communications
to a file.

THAT is how I would have done it. Problem is that it is a real pain to
do VT100 emulation great and putty does a much better job than I.



_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users