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.
You mean, there's nothing else in the Shuffle_struct you need there? Otherwise I'd like to point out that you can't reliably convert a struct object * to a pointer to your storage since it might be inherited multiple times.
- 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.
Sorry for being a bit late in responding to this. I think it's an interface problem between the Fd class and Shuffler. The solution is to either take over the fd from the Fd object so that it temporarily becomes closed, or continue using the box directly in it.
In the first case, the Fd class should provide an release_fd() function which works like query_fd() but additionally deregisters the fd from itself (by using change_fd_for_box(&THIS->box,-1) to keep callback settings and backend pointers). The Fd object is then effectively closed during the time the shuffler uses the fd. Afterwards the shuffler should use another function, say Fd.take_fd, which does the reverse, after the shuffler has decommissioned its own box. Fd.open can already take an fd, but I don't think it does the right thing here since it sets FILE_NOT_OPENED too.
If you want the Fd object to continue working in parallell then you need to add an interface to it so that it can chain on to your callback, i.e. sort of a C level equivalent to the pike callback interface. It would presumably consist of an fd_box_callback, a pointer to your own storage, and the events bitfield. Another possibility is to simply use the pike level callbacks here too, but that might give problems with cyclic references.
In either case, there's no need to do anything at all in backend.cmod.
Your solution right now where you unhook the box in the Fd object under its feet is dangerous since the Fd object assumes that its box stays hooked. For instance, what happens if someone destructs it while the shuffler uses its fd? What happens if pike callbacks are registered? Are they silently ignored while the shuffler callbacks take precedence? If so, is that really right?
/ Martin Stjernholm, Roxen IS
Previous text:
2004-06-27 03:28: Subject: Two fd_boxes, same FD (Re: Drowning in the Shuffler (SEGV))
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.
Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).
Real programmers don't produce results, they return exit codes.
/ Brevbäraren