Stephen R. van den Berg wrote:
I retried converting the Shuffler to the new fd_boxes... (The fix I did stands, BTW, it's just that there is more damage than meets the eye).
Fixed it good now. I think. Per Hedbor, Martin Stjernholm, please verify what I came up with.
Regarding your question "must be first?": Yes, it looks like it must be first since you implicitly convert a pointer to the box to a pointer to Shuffle_struct in e.g. _send_more.
Yes. Found that out, after adding the struct member. Anyway, it's not required anymore, since I use ref_obj now.
Well, not quite. Had to resort to some good old fashioned offsetof() trick to make it work due to the hidden struct members. This trick can be used in the other source files as well, so that the box element doesn't need to be first anymore.
Now, this descriptor is given (temporarily) to the shuffler, to write out any data it wants to write, then, the descriptor should be used by http.pike again to accept further requests on the kept-alive connection.
The problem obviously is, that the shuffler tries to setup an FD_BOX on that same FD. The FD_BOX code complains (rightfully so).
So, should I extend the interface in backend.cmod to allow retrieving the old handler, so the shuffler can take evasive action?
This is what I ended up doing. Not sure if this is the cleanest solution, but it sure was the most non-intrusive change in the backend code.
Or, should I extend the fd_box to include some kind of chain pointer to the previous fd_box, which are then all called in succession by the backend handler?
I briefly tried this first. But after finding that there active and non-active lists of FD boxes, I decided to give up on this, too convoluted for a solution which will only be used in the Shuffler.
Or, should the shuffler do something clever with the backend setting?
I couldn't come up with anything sensible.
Please advise.
Change that into, please review; checking in proposed changes now (it seems to work now).