 |
 |
I agree that it's a security bug that needed fixing. What I was asking is: why did we end up in this situation in the first place. By sending `kXR_waitresp` the server essentially indicates to the client that it is impossible to answer immediately and the client may need to wait a long time for the answer. The server then answers so fast that it causes a data race in the client, it's a bit strange :) By returning `Take` the handler indicates to the queuing system that it wants to consume the current message and the message should not be given to any other handler. By returning `Ignore` the handler tells the queuing system that it is not interested and other handlers should be polled. Returning both `Take` and `Ignore` at the same time is a bit confusing. It would be probably better to add another flag called `Sync` that would cause the queuing system to call the handler from current context instead of scheduling the asynchronous job. This way Elvin probably wouldn't have to add clarifying comments :) --- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/290#issuecomment-146465294 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1