Re: Thoughts on a line-at-a-time data-reading class
Re: Thoughts on a line-at-a-time data-reading class
- Subject: Re: Thoughts on a line-at-a-time data-reading class
- From: Jens Alfke <email@hidden>
- Date: Thu, 10 Mar 2016 09:40:03 -0800
> On Mar 9, 2016, at 11:53 PM, Daryle Walker <email@hidden> wrote:
>
> In my head, I came up with (in Swift):
This is exactly the kind of thing that frustrates me about the Cocoa APIs: they’re so very bad at streams and producer/consumer patterns. This kind of problem really calls out for a proper stream API, not to mention channel-based concurrency. (An implementation in Go is trivial — you start a goroutine that reads from a stream until it accumulates a line, then writes the string to a channel.)
Anyway, given the Foundation APIs we have, your solution seems reasonable.
> I have the algorithm in mind for the parsing, then realized that the handling needed to wait for the single line-break characters in case a paired character followed may be generalized.
That’s reasonable in the case of reading from a file. But if you want this to be a general purpose library that might read from a network socket, then you’re about fall into a trap that I saw pretty often in Java apps running on Mac OS 8/9. This would happen with code implementing some kind of line-oriented protocol like FTP:
— Client sends a command, terminated with a CR (because it’s running on Mac OS 9 where CR was the default line ending.)
— Server parses the line and the CR, and decides it won’t signal end-of-line until it reads the next byte, in case it’s an LF.
— Server is now waiting to receive another byte, before it sends the command to the command parser.
— Client is now waiting to receive the response to its command, before it sends any more data.
— Deadlock!
This was due to a bug in the Java InputStream’s readLine method in Java 1.1. This was fixed in 1.2 by having readLine return the line after receiving the CR, but it also sets a flag reminding itself that if the next byte received is an LF it should ignore it.
Maybe this is irrelevant and/or TMI, but your post caused me to flash back to a common, and hard to debug, support problem circa 1999, so I had to [over]share :)
—Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden