redoste
/
fxlink-gdb-proxy
1
0
Fork 0
Code Issues Pull Requests Releases Activity

Read fxlink messages in a loop to properly flush the new IN queue 

This is required since Lephenixnoir/fxsdk@85d7fcf9e9 as new messages are
now added to a queue to fix a race condition that occurred because it's
possible to read more than one in a single libusb_handle_events().

See Lephenixnoir/gint#27
This commit is contained in:
redoste 2024-03-26 00:22:42 +01:00
parent 8c41aba127
commit c01efc7804
Signed by: redoste
SSH Key Fingerprint: SHA256:Y1z/cbVN8OVoFPXzVgklSqoZnyQQ/PQM8YwhMtxMk90
1 changed files with 6 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
src/main.c
View File

@ -115,8 +115,8 @@ int main(int argc, char* argv[]) {
struct timeval zero = {0};
libusb_handle_events_timeout(context, &zero);
struct fxlink_message* msg = fxlink_device_finish_bulk_IN(dev);
if (msg) {
struct fxlink_message* msg;
while ((msg = fxlink_device_finish_bulk_IN(dev)) != NULL) {
if (!fxlink_message_is_apptype(msg, "gdb", "remote")) {
elog("unknown fxlink message type\n");
ret = -1;
@ -130,15 +130,13 @@ int main(int argc, char* argv[]) {
}
fxlink_message_free(msg, true);
// TODO : Uhu ?
/* if (!fxlink_device_start_bulk_IN(dev)) {
* elog("unable to start bulk IN trasfer\n");
* return -1;
* }
*/
fxlink_device_start_bulk_IN(dev);
}
if (ret != 0) {
break;
}
// We don't want to start a new OUT transfer if another one is still in progress
if (!dev->comm->ftransfer_OUT) {
int bytes_socket;