moz.build |
|
1096 |
neqo |
|
|
neqo_glue |
|
|
nsINamedPipeService.idl |
nsINamedPipeDataObserver
This is the callback interface for nsINamedPipeService.
The functions are called by the internal thread in the nsINamedPipeService.
|
2305 |
nsISocketProvider.idl |
nsISocketProvider
|
5575 |
nsISocketProviderService.idl |
nsISocketProviderService
Provides a mapping between a socket type and its associated socket provider
instance. One could also use the service manager directly.
|
699 |
nsNamedPipeIOLayer.cpp |
Both blocking/non-blocking mode are supported in this class.
The default mode is non-blocking mode, however, the client may change its
mode to blocking mode during hand-shaking (e.g. nsSOCKSSocketInfo).
In non-blocking mode, |Read| and |Write| should be called by clients only
when |GetPollFlags| reports data availability. That is, the client calls
|GetPollFlags| with |PR_POLL_READ| and/or |PR_POLL_WRITE| set, and
according to the flags that set, |GetPollFlags| will check buffers status
and decide corresponding actions:
-------------------------------------------------------------------
| | data in buffer | empty buffer |
|---------------+-------------------------+-----------------------|
| PR_POLL_READ | out: PR_POLL_READ | DoRead/DoReadContinue |
|---------------+-------------------------+-----------------------|
| PR_POLL_WRITE | DoWrite/DoWriteContinue | out: PR_POLL_WRITE |
------------------------------------------+------------------------
|DoRead| and |DoWrite| initiate read/write operations asynchronously, and
the |DoReadContinue| and |DoWriteContinue| are used to check the amount
of the data are read/written to/from buffers.
The output parameter and the return value of |GetPollFlags| are identical
because we don't rely on the low-level select function to wait for data
availability, we instead use nsNamedPipeService to poll I/O completeness.
When client get |PR_POLL_READ| or |PR_POLL_WRITE| from |GetPollFlags|,
they are able to use |Read| or |Write| to access the data in the buffer,
and this is supposed to be very fast because no network traffic is
involved.
In blocking mode, the flow is quite similar to non-blocking mode, but
|DoReadContinue| and |DoWriteContinue| are never been used since the
operations are done synchronously, which could lead to slow responses.
|
25946 |
nsNamedPipeIOLayer.h |
|
725 |
nsNamedPipeService.cpp |
Implement nsINamedPipeService
|
8128 |
nsNamedPipeService.h |
The observers is maintained in |mObservers| to ensure valid life-cycle.
We don't remove the handle and corresponding observer directly, instead
the handle and observer into a "retired" list and close/remove them in
the worker thread to avoid a race condition that might happen between
|CloseHandle()| and |GetQueuedCompletionStatus()|.
|
2197 |
nsSocketProviderService.cpp |
|
2551 |
nsSocketProviderService.h |
nsSocketProviderService_h__ |
850 |
nsSOCKSIOLayer.cpp |
|
45223 |
nsSOCKSIOLayer.h |
nsSOCKSIOLayer_h__ |
776 |
nsSOCKSSocketProvider.cpp |
|
3505 |
nsSOCKSSocketProvider.h |
nsSOCKSSocketProvider_h__ |
835 |
nsUDPSocketProvider.cpp |
|
1553 |
nsUDPSocketProvider.h |
nsUDPSocketProvider_h__ |
552 |