|
|
Line 13: |
Line 13: |
| == API target: sending OnDataAvailable() to other threads == | | == API target: sending OnDataAvailable() to other threads == |
|
| |
|
| In a perfect world, our goal would be an API where any thread could use the full necko interface, and initiate and process network requests completely independently. However, while there's no theoretical reason why necko couldn't be made fully re-entrant, the implementation obstacles involved would be considerable (see notes at end for some details).
| | This API allows non-main threads be allowed to directly receive the OnDataAvailable() call from the nsIStreamListener interface. All setup of the network channel before this point (and possibly after) would need to be handled on the main thread (i.e. the non-main thread would not call any necko functions itself: it would instead arrange for the main thread to call them). |
|
| |
|
| Benjamin Smedberg suggested a much more modest goal: that non-main threads be allowed to directly receive the OnDataAvailable() call from the nsIStreamListener interface. All setup of the network channel before this point (and possibly after) would need to be handled on the main thread.
| | The OnDataAvailable() delivery appears to be sufficient for the existing use cases for which a multithreaded necko has been requested: most notably, for an off-main-thread HTML parser. |
| | |
| The meeting quickly came to a consensus that something like this would be sufficient for the existing use cases for which a multithreaded necko has been requested: most notably, for an off-main-thread HTML parser to be able to stream in HTML from the network without interfering/delaying the main thread (and vice versa).
| |
|
| |
|
| There still remain, however, some questions about the exact API: | | There still remain, however, some questions about the exact API: |