[guardian-dev] Fwd: libaccesspoint concurrency help

[Michael Rogers]

On 14/05/15 16:46, Daniel Martí wrote:
> 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.

Thanks man!

>> 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.

Yup, I had a similar thought about adding a "no more results" method to
the interface. It's something I missed in the Bluetooth LE API when
playing with it recently.

>> 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.

Maybe that points towards making both methods asynchronous - unless
/proc/net/arp is guaranteed not to block.

>> 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?

There are many situations where I'd suggest using final, but that's the
only one that's relevant to this particular piece of code.

Cheers,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20150518/bf9a87f3/attachment.sig>