Skip to content
This repository has been archived by the owner on Oct 2, 2019. It is now read-only.

Dynamically changing arrays could lead to race conditions #81

Open
marcoscaceres opened this issue Jun 7, 2013 · 9 comments
Open

Dynamically changing arrays could lead to race conditions #81

marcoscaceres opened this issue Jun 7, 2013 · 9 comments
Milestone

Comments

@marcoscaceres
Copy link
Contributor

There are a few attributes that are currently defined as an array, that could change dynamically during an application's lifecycle, namely:

  • serviceIds
  • emergencyNumbers
  • calls

This could lead to unexpected behavior and race conditions. For example, the user pops out a sim card or a call hangs up while a script is in the middle of a for loop.

I recommend that we change the above to methods that return a sequence instead. That will just return an array that is a copy of the current state of the system as some moment in time. That should prevent strange race conditions from happening.

@zolkis
Copy link
Contributor

zolkis commented Jun 14, 2013

Changes in the 'calls' and 'serviceIds' arrays are signaled by events. serviceIds could be made a sequence, but I would not make 'calls' a sequence. emergencyNumbers array is updated when a service appears enabled, but indeed there is no event for that other than when the 'serviceadded' signal is fired, emergencyNumbers is regenerated by implementation (in my implementation). I wonder if should this be the pattern, and should we state it in the spec this way, or should we spec a new event for the 'emergencynumberschanged'.

@marcoscaceres
Copy link
Contributor Author

The problem with leaving things as an array is that developers can change stuff in those arrays, copy them by reference, etc. That seems really messy. Like:

var calls = navigator.telephony.calls; 
calls.push("whatever"); 

If calls is a sequence, then the developer can request the current list of calls and do whatever they want with the array without affecting the actual call attribute's value... like:

var calls = navigator.telephony.calls(); 
while(calls.length){
   calls.pop().hold();
}

@marcoscaceres
Copy link
Contributor Author

FWIW, I do think we should add emergencynumberschanged event.

@zolkis
Copy link
Contributor

zolkis commented Jun 21, 2013

With the current API it is likely it will be never fired, but yes, we can add.

@marcoscaceres
Copy link
Contributor Author

I had a really good discussion about sequences over on public-script-coord:
http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0748.html

I think we are going to have to change to using getCalls(), etc.

@zolkis
Copy link
Contributor

zolkis commented Jun 26, 2013

The primary usage of getCalls() is to fetch the initial list of call object references when starting up, then monitor the calls solely by events.
Of course, apps can invoke getCalls() any number of time, but not much use.
Apps must not write the call array. For adding a call, must dial, and for removing a call, must disconnect.

@marcoscaceres
Copy link
Contributor Author

So, with getCalls(), the calls array becomes an internal thing (which is a good thing). Then the rest is monitored with events.

For the utility, see the second example in my comment above.

@zolkis
Copy link
Contributor

zolkis commented Sep 27, 2013

Could we use Promises returning a sequence of objects/id's?
Is it canonical to writePromise<sequence<Call>> ?

@marcoscaceres
Copy link
Contributor Author

No, there is currently no support for that in WebIDL

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants