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).
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Btw, you probably can replace this_obj with box.ref_obj, provided this_obj is what it looks like.
Ok, done.
I put it in the same struct, and removed the fd there. So that should be about right.
If you say so. Wasn't there some circumstances when other fd's could be passed to the callbacks or something like that?
No. Not that I noticed.
What springs to mind, is, is using INIT_FD_CALLBACK_BOX in just the INIT section enough? Or should it be repeated at create time?
Yes and no. An already hooked box must not be hooked in again.
Ok, understood it mostly. Know more about these boxes than I ever intended now :-).
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.
However... The following problem occurs:
ChiliMoon server, has a file descriptor on a kept alive connection to the client requesting a web page. This descriptor is already hooked on an FD_BOX from within http.pike.
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). How are we going to solve this? - The current Stdio code does not allow me to unhook the FD box temporarily, so fixing it from within http.pike is impossible. - The Shuffler has no way to get at the old handler and temporarily disable it, and/or chain to it.
So, should I extend the interface in backend.cmod to allow retrieving the old handler, so the shuffler can take evasive action? 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? Or, should the shuffler do something clever with the backend setting?
Please advise.