Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Changes to AdapterManager & Adapter

8 views
Skip to first unread message

David Rajchenbach-Teller

unread,
Mar 30, 2016, 11:17:08 AM3/30/16
to dev-proj...@lists.mozilla.org
I am currently in the process of landing a new version of
AdapterManager. It will change a few things for Adapter developers, so
here's a short summary.



# What's wrong at the moment

Currently, the Foxbox responds to requests as follows:

- whenever we receive an HTTP request, we acquire a Mutex;
- while in the Mutex, we dispatch the single request to the AdapterManager;
- still while in the Mutex, the AdapterManager dispatches the request to
any number of Adapters;
- once all Adapters have responded, the Mutex is lifted;
- once the Mutex is lifted, the Foxbox responds to the HTTP request.

This has two consequences:
- if *any device* takes several seconds to respond, *all HTTP requests*
are blocked during these several seconds;
- as discovered during the work week, if *any Adapter* attempts to call
the AdapterManager from a callback, the *entire FobBox will deadlock*.



# What's new

The patch changes the behavior of the Foxbox as follows:

- the AdapterManager is now Sync;
- the AdapterManager now holds an internal read-write lock;
- at any moment, the AdapterManager supports either *one* write call
(adding/removing an adapter/service/channel/tag/watch) or *any number*
of read calls (getting the list of adapters/services/channels, sending
values to channels, fetching values from channels);
- all interactions with Adapters is performed out of the lock.

Basically this means:
- unless all threads are busy, a device taking several seconds to
respond will only slow down its own HTTP request;
- an adapter can callback into the AdapterManager, without deadlock.




# Consequences for Adapter developers

- Adapters are supposed to implement Sync.
- instead of taking a Box<AdapterManagerHandle>, Adapters are expected
to take a &Arc<AdapterManager>;
- instead of providing a Box<Adapter>, Adapters are now expected to
provide a &Arc<Adapter>.

I have a draft utility that implements Sync automatically for Adapters
in a very non-optimal way, I'll try and land this later today or tomorrow.


Cheers,
David
0 new messages