On Thu, May 14, 2015 at 11:55:29 +0100, Michael Rogers wrote: > Sorry if my comments yesterday came across as blunt - it was a long day. :-)
No problem. It was me who was asking for help. > Yup, waiting on a background thread is the important part. I agree that > futures work just as well as a latch. I think futures waits for all to finish, though. I was thinking of adding another callback interface method like "no more clients to be found", so I'd like to do that once all threads are done. If I use futures, I think I'll just do all callbacks once all threads are done, in which case a counter or latch would be better. > Maybe I'm being overly picky, but I don't see the point of providing a > convenience method that makes it easier for people to do the wrong > thing, and sample code that shows how to do the wrong thing. If you > intend people to use this method correctly, why not show them how? > > [...] > > Good point. :-) However, what you essentially have here is two methods > for doing the same thing: one synchronous, the other asynchronous. If > you want the code to be less verbose, the synchronous method can be a > thin wrapper around the asynchronous method or vice versa. Or even > better, just have one method and then show in your sample code how it > can be wrapped. You're probably right. But one part of me thinks that getClients() does I/O on /proc/net/arp anyway. Granted that the timeout of a few hundreds of milliseconds for the network stuff is much larger, but in a way they both do I/O. > Hope that helps, and I apologise for the verbose explanation of a > verbose language. :-) So you would suggest never using final except in that specific scenario? -- Daniel Martí - [email protected] - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C
pgpavjIP7VvRe.pgp
Description: PGP signature
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
