[guardian-dev] Fwd: libaccesspoint concurrency help

Daniel Martí mvdan at mvdan.cc
Thu May 14 11:46:21 EDT 2015


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í - mvdan at mvdan.cc - http://mvdan.cc/
PGP: A9DA 13CD F7A1 4ACD D3DE  E530 F4CA FFDB 4348 041C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20150514/51dbc917/attachment.sig>


More information about the guardian-dev mailing list