David Rajchenbach-Teller
unread,Mar 30, 2016, 11:17:08 AM3/30/16You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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