gssproxy

#217 Fix concurrency bug in sending command replies
Closed by simo. Opened by simo.
simo/gssproxy concufix  into  master

Download 217.patch

If multiple threads were ready at the same time we would process only the
first and then leave the rest hanging.
Try to process all the replies in the reply queue and then also try to
put as many workers as possible back to work on queued requests.

@rharwood PTAL

LIST_DEL? Not that we ever use the prev pointer for anything, but it would be a nasty surprise...

Probably should be a LIST_ADD anywhere the wait_list or other worker lists are manipulated too.

One comment inline.

The concurrency looks right, so if you're okay with the list macros, I can clean up and merge.

Closing this one, my root cause analysis was incorrect and the current code, while less efficient in some corner case, seem to work correctly.
I'll revive this one in the fure if we see the need

Pull-Request has been closed by simo
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.