Skip to content

Don't mix coalesce calls from multiple GeoJSON sources (issue #5970) - #5983

Closed
ChrisLoer wants to merge 2 commits into
masterfrom
cloer-5970
Closed

ChrisLoer wants to merge 2 commits into
masterfrom
cloer-5970

Conversation

@ChrisLoer

Copy link
Copy Markdown
Contributor

Fixes issue #5970.

Also: send back an "abandoned" callback for coalesced calls so that foreground doesn't leak callback handles.

Adds 'loadData' unit test for geojson_worker_source that simulates building up a queue of loadData messages.

/cc @ansis @jfirebaugh @anandthakker

Also: send back an "abandoned" callback for coalesced calls so that foreground doesn't leak callback handles.
Add 'loadData' unit test for geojson_worker_source that simulates building up a queue of loadData messages.
@jfirebaugh

Copy link
Copy Markdown
Contributor

Hrm... not too thrilled with the additional state tracking this solution requires.

What would it take to be able to truly self-send the coalesce method?

@ChrisLoer

Copy link
Copy Markdown
Contributor Author

I did manual testing against the 2000 circle example from #5716 (comment) -- performance feels similar.

@ChrisLoer

Copy link
Copy Markdown
Contributor Author

What would it take to be able to truly self-send the coalesce method?

I'm not sure -- I don't think we have a way to directly access the worker's message queue. Maybe we could build a wrapper/shadow of the message queue and push the self-send there? I don't see how we could manage the order correctly though, since we don't have a good way to know when we've temporarily emptied the real message queue (i.e. when it's time to insert our "self sent" messages).

Self-sending would be a simplification, but it wouldn't address either of the issues in this PR -- we'd still have to maintain state separately for sources that share a worker, and we'd still have to send back "abandoned" callbacks to the foreground.

* @param callback
*/
loadData(params: LoadGeoJSONParameters, callback: Callback<void>) {
loadData(params: LoadGeoJSONParameters, callback: Callback<boolean>) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't the params and callback need to be stored on a per-source basis as well?

I think the root problem here is that WorkerSources should be per-source, not per-source-type. The mapping from source ID to WorkerSource instance should be handled by Worker.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't the params and callback need to be stored on a per-source basis as well?

Oh, of course. Good catch.

I think the root problem here is that WorkerSources should be per-source, not per-source-type. The mapping from source ID to WorkerSource instance should be handled by Worker.

🤔 That sounds convincing, although I'd like to handle it in a different PR. On a quick inspection, it looks like the StyleLayerIndex is the main thing that would remain shared between multiple WorkerSources?

- Store 'pendingCallback' and 'pendingLoadDataParams' per-source
- Store all source-related parameters (with exception of super 'loaded' parameter) in one dictionary
- Remove pending callbacks associated with a source when the source is removed
- Handle case in which 'coalesce' arrives after source has been removed
- Add unit test that would catch callbacks being shared between sources
@ChrisLoer

Copy link
Copy Markdown
Contributor Author

I addressed the params/callback problem, and in the process noticed a further race condition between removeSource and coalesce. I'm looking now at modifying worker.js to store one WorkerSource per source, although I'm a little worried about unintended consequences of that change (especially if we're going to do it in v.44).

@anandthakker

anandthakker commented Jan 12, 2018 •

Copy link
Copy Markdown
Contributor

@ChrisLoer @jfirebaugh when a worker sends a message to the main thread, the response is queued right along with other main-thread-initiated messages, right? So another approach to the coalesce message would be to have the worker source send coalesce to the main thread and wait for it to bounce back. Still not a true self-coalesce... but maybe that simulates it slightly better? Not sure.

@ChrisLoer

Copy link
Copy Markdown
Contributor Author

@anandthakker My first implementation worked with the worker sending an explicit coalesce message to the main thread -- I think it's pretty similar to the current approach of having the main thread loadData callback send coalesce to the worker, but just has one extra message (and extra handling code).

@anandthakker

Copy link
Copy Markdown
Contributor

@ChrisLoer this is subsumed by #5988 now, right?

@ChrisLoer

Copy link
Copy Markdown
Contributor Author

Yup.

@ChrisLoer ChrisLoer closed this Jan 22, 2018
@ChrisLoer
ChrisLoer deleted the cloer-5970 branch January 22, 2018 18:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants