Age | Commit message (Collapse) | Author |
|
When a call to disconnect() failed, the
connect() callback was cleared, not the
disconnect() one. This would cause deadlocks,
where JNI threads were forever blocked on
doConnect().
Bug: 7324226
Change-Id: I784c8d700c87d643315f2417610ca75ef8f9aa7c
|
|
On Android we now start connecting SNEP/other LLCP
services as soon as the link comes up. That means
we will have connect requests incoming, accept
responses outgoing, connect requests outgoing and
accept responses incoming.
This lays bare a lot of threading issues in this lib.
Since the receives come in serialized, those typically
do not cause any issue. However, we may be sending
something on a thread coming from the NfcService,
while at the same time we'll receive for example
a connect frame from the remote, to which the receive
thread immediately wants to send a response.
This is a first attempt at making sends thread-safe:
already there was a lot of logic to deal with the fact
that another send was in progress, in the form of the
bSendPending variable. That variable was however
not checked atomically, and some operations did not
even set it correctly.
This change tests and sets that variable atomically,
more or less implementing a semaphore with try-acquires
and fallbacks for the failure case.
The generic structure is:
if (testAndSetSendPending()) {
// Another thread is sending, stash data
// and most importantly do *NOT* change shared data
} else {
// We're now the only one sending, we're free
// to change shared data until the callback is
// called.
}
This is just a band-aid fix, but given the fact that
this stack will be deprecated it is hopefully enough
for our planned usecases.
A decent fix would involve switching to
a TX-queue per socket, and a generic TX-queue
for the whole LLCP link. This allows us to fully
decouple the connection layer from the transport
layer, as it should be.
Change-Id: Ibd8742f7350a58459771f5036a049af3a487f783
|
|
This enables the server to avoid losing packets, especially when
receiving them in an aggregated packet. The size of the buffer is
determined by the size of the working buffer provided by the application.
Change-Id: Ia3c72e19fdb74e2a43390af5607c497c2275fe46
|
|
The pending operations were handled at the connection-oriented sockets
level, with no possibility for other transport types to handle
pending operations.
A dispatcher has been added at the generic transport level to
remove this limitation.
This feature is needed to implement LLCP v1.1.
Change-Id: I69e37ba800d1c531396ca97ab0a0480e0f53d63f
|
|
When a connectionless socket is closed, Connectionless_Abort()
is called, which in turn calls the send and receive callbacks
to indicate abortion. But since these callbacks are not cleared
out after a previous send/receive has completed, this can lead
to spurious callbacks and consequently memory corruption.
Change-Id: Iea7a34829c4db1cae3b49f33117b25b50205683f
|
|
This ensure the lib client not to be stuck waiting for a callback when
the socket has been closed meanwhile.
Change-Id: I9cdfa3c2cc75ee9451c3ad5b92eb338b5e68f53a
|
|
Socket options are now copied in the libnfc to avoid referencing a pointer that
may not be valid during the whole socket life cycle.
Change-Id: I7266164bf157242df1ce7fb7a0f9cffd52938140
Signed-off-by: Nick Pelly <npelly@google.com>
|
|
Service Name is now copied in the libnfc to avoid referencing a pointer that
may not be valid during the whole socket life.
Change-Id: I6572366ac51502d189cc8f1350fa089c11cc2bea
|
|
Source: Trusted_NFC_Device_Host_AA03.01e02_google.zip code drop (23-Sep-2010)
Change-Id: Ie47f18423f949a8d3e0815d13f55c814312add24
Signed-off-by: Nick Pelly <npelly@google.com>
|