GeckoProfile file operations should be async

RESOLVED INACTIVE

Status

()

Firefox for Android
General
P5
normal
RESOLVED INACTIVE
6 years ago
3 days ago

People

(Reporter: kats, Unassigned)

Tracking

unspecified
All
Android
Points:
---

Firefox Tracking Flags

(blocking-fennec1.0 -)

Details

See https://bugzilla.mozilla.org/show_bug.cgi?id=726382#c9 - this bug is a follow-up to ensure that the read and move file functions in GeckoProfile.java are made async.
@kats: Don't those functions require values to be returned? So performing those functions asynchronously wouldn't really yield any particular benefit in this case, since we would need to join the asynchronous operation before returning the values? I'm not sure if that's what you meant, but lemme know, and I'll try to help with this.
Assignee: nobody → jdhaliwal
We may have to alter the callers (one by one if that's easy). I just don't like having synchronous api's around. They encourage me to write bad code. This is not high priority IMO.
Hmm, well that's another situation then. The synchronous keyword in Java essentially just allows for it to act as a monitor (mutex) function, so it shouldn't really affect much for people using the API I think. The only thing that really changes is that callers would be handled by the system to be synchronously allowed to access the function, which might be necessary if we've got multiple callers trying to read the same file at the same time. If that's the intended behaviour, it should be relatively simple to fix.
:Arreth, you had it right in comment #1. What :wesj was saying in comment #2 is that instead of joining on the asynchronous operation right after initiating it, we can initiate it a little bit beforehand (at the point we know we'll be needing it) and do stuff before having to join on it (which is the point we actually *use* the return value). You'd have examine all the places that invoke these operations to see if that is feasible or not.
@kats:
In GeckoProfile.java, as well as the other files which make use of the readFile/readSessionFile functions, the calls are performed just about as early as possible, and there wouldn't be very much, if any benefit at all, to performing these calls in the background since there aren't very many steps to be done in the mean time before the return value is needed, and the overhead of thread processing might outweigh the benefits.

Lemme know if you (or anyone else for that matter) had and opinions/comments about this :)
That's kind of what I suspected would be the case. wesj, any thoughts?
blocking-fennec1.0: --- → ?
tracking-fennec: --- → +
blocking-fennec1.0: ? → -
Priority: -- → P3
Assignee: jdhaliwal → gbrown
Sorry. My reply we lost I think.

This is about removing this api to save people from hurting themselves, not about current callers (although current callers should be rewritten to use a better api). I think all of the current callers already run their own AsyncTask for doing this, or dispatch to the GeckoThread.

I think we could have something like:

void readFile(aFile, new readFileCallback() {
  public void gotFile(String data);
});
I can never seem to get around to this...freeing it up for someone else.
Assignee: gbrown → nobody
Whiteboard: [mentor=wesj]
(Assignee)

Updated

4 years ago
Mentor: wjohnston
Whiteboard: [mentor=wesj]
Since the last update is more than 2 years, we are removing the tracking-fennec flag for now.
Feel free to renominate the bug if it happens again and it's reproducible. 

Thank you !
tracking-fennec: + → ---
Priority: P3 → P5
Mentor: wjohnston2000

Comment 10

3 days ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 3 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.