mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-12-04 11:26:09 +00:00
01583602a9
The bulk of this commit was generated with a script, executed at the top level of a typical source code checkout. The only non-machine-generated part was modifying MFBT's moz.build to reflect the new naming. CLOSED TREE makes big refactorings like this a piece of cake. # The main substitution. find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \ xargs perl -p -i -e ' s/nsRefPtr\.h/RefPtr\.h/g; # handle includes s/nsRefPtr ?</RefPtr</g; # handle declarations and variables ' # Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h. perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h # Handle nsRefPtr.h itself, a couple places that define constructors # from nsRefPtr, and code generators specially. We do this here, rather # than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename # things like nsRefPtrHashtable. perl -p -i -e 's/nsRefPtr/RefPtr/g' \ mfbt/nsRefPtr.h \ xpcom/glue/nsCOMPtr.h \ xpcom/base/OwningNonNull.h \ ipc/ipdl/ipdl/lower.py \ ipc/ipdl/ipdl/builtin.py \ dom/bindings/Codegen.py \ python/lldbutils/lldbutils/utils.py # In our indiscriminate substitution above, we renamed # nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up. find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \ xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g' if [ -d .git ]; then git mv mfbt/nsRefPtr.h mfbt/RefPtr.h else hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h fi --HG-- rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h |
||
---|---|---|
.. | ||
build | ||
standalone | ||
test | ||
testlib | ||
third_party | ||
common.build | ||
databuffer.h | ||
dtlsidentity.cpp | ||
dtlsidentity.h | ||
gonk_addrs.cpp | ||
logging.h | ||
m_cpp_utils.h | ||
moz.build | ||
nr_socket_prsock.cpp | ||
nr_socket_prsock.h | ||
nr_timer.cpp | ||
nricectx.cpp | ||
nricectx.h | ||
nricemediastream.cpp | ||
nricemediastream.h | ||
nriceresolver.cpp | ||
nriceresolver.h | ||
nriceresolverfake.cpp | ||
nriceresolverfake.h | ||
nrinterfaceprioritizer.cpp | ||
nrinterfaceprioritizer.h | ||
README | ||
rlogringbuffer.cpp | ||
rlogringbuffer.h | ||
runnable_utils.h | ||
sigslot.h | ||
simpletokenbucket.cpp | ||
simpletokenbucket.h | ||
stun_udp_socket_filter.cpp | ||
stun_udp_socket_filter.h | ||
test_nr_socket.cpp | ||
test_nr_socket.h | ||
transportflow.cpp | ||
transportflow.h | ||
transportlayer.cpp | ||
transportlayer.h | ||
transportlayerdtls.cpp | ||
transportlayerdtls.h | ||
transportlayerice.cpp | ||
transportlayerice.h | ||
transportlayerlog.cpp | ||
transportlayerlog.h | ||
transportlayerloopback.cpp | ||
transportlayerloopback.h | ||
transportlayerprsock.cpp | ||
transportlayerprsock.h |
This is a generic media transport system for WebRTC. The basic model is that you have a TransportFlow which contains a series of TransportLayers, each of which gets an opportunity to manipulate data up and down the stack (think SysV STREAMS or a standard networking stack). You can also address individual sublayers to manipulate them or to bypass reading and writing at an upper layer; WebRTC uses this to implement DTLS-SRTP. DATAFLOW MODEL Unlike the existing nsSocket I/O system, this is a push rather than a pull system. Clients of the interface do writes downward with SendPacket() and receive notification of incoming packets via callbacks registed via sigslot.h. It is the responsibility of the bottom layer (or any other layer which needs to reference external events) to arrange for that somehow; typically by using nsITimer or the SocketTansportService. This sort of push model is a much better fit for the demands of WebRTC, expecially because ICE contexts span multiple network transports. THREADING MODEL There are no thread locks. It is the responsibility of the caller to arrange that any given TransportLayer/TransportFlow is only manipulated in one thread at once. One good way to do this is to run everything on the STS thread. Many of the existing layer implementations (TransportLayerPrsock, TransportLayerIce, TransportLayerLoopback) already run on STS so in those cases you must run on STS, though you can do setup on the main thread and then activate them on the STS. EXISTING TRANSPORT LAYERS The following transport layers are currently implemented: * DTLS -- a wrapper around NSS's DTLS [RFC 6347] stack * ICE -- a wrapper around the nICEr ICE [RFC 5245] stack. * Prsock -- a wrapper around NSPR sockets * Loopback -- a loopback IO mechanism * Logging -- a passthrough that just logs its data The last three are primarily for debugging.