/.../ the application calling the Shuffler should know better than to try funny things with the FD while they have been passed on to the Shuffler.
Certainly, but bugs do occur and simultaneous use of the same fd from different places is typically tricky to sort out (the oldest and most bothersome bugs with ssl connections were due to that). It's really valuable to get good errors when you do something wrong; it happens to the best of us.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-07-01 17:18: Subject: Re: Two fd_boxes, same FD (Re: Drowning in the Shuffler (SEGV))
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
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.
Erm, found that out shortly after writing previous message, that's why I'm using yet another method in the "final" fix (offsetof).
- The current Stdio code does not allow me to unhook the FD box temporarily, so fixing it from within http.pike is impossible.
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.
Ok, I'll pick method one, I think.
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
No need, the "specs" for the Shuffler say that it takes over the connection; would be a bit pointless if it didn't.
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?
Well, I know the solution has flaws. But, in defense of the current solution, the application calling the Shuffler should know better than to try funny things with the FD while they have been passed on to the Shuffler. -- Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).
"The difficult we do today; the impossible takes a little longer."
/ Brevbäraren