Re: How to do a blocking read from a serial device?
site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Jul 11, 2006, at 12:11 PM, Michael Smith wrote: Read(2) will block if there is no data so there's no need to sleep. Using select(2) is one way to go about it but with only one file descriptor/socket, it seems pointless to me. Shouldn't that return -1 or 0? -- Steve Checkoway _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com On Jul 11, 2006, at 12:04 PM, darwin-dev-request@lists.apple.com wrote: Select(2) makes timeout handling (mandatory for disconnectable devices such as those attached by USB or serial interfaces) much simpler. I note in your example that you don't test for ret == 0, which in the case of a blocking read means that if the fd is closed for some reason (e.g. the device is destroyed due to removal) you will spin forever. You're right. That's what happens when I write code in mail right after waking up. =) IMO, select with a non-blocking fd is a much cleaner way to implement this; it also has the advantage of making additions to the code over time much simpler, as it's an architectural stepping stone to a state-machine. I agree with the latter statement. For the former, I'm not sure. It tends to lead to a long while loop consisting of checking if you can read from each of the fds, reading from them, handling whatever that was supposed to do, then doing the same for writing. When dealing with multiple streams, this is the way to go. If there is only one and will only ever be one, I think it's the wrong way to go unless it's required for the timeout handling. smime.p7s
participants (1)
-
Steve Checkoway