On 12. 12. 25 23:48, Branko Čibej wrote:
On 12. 12. 25 20:49, Branko Čibej wrote:
The problem is that the error callback is global, not connection- or
at least context-specific. That simply doesn't scale.
In addition to not scaling, it's also a headache for Serf's threading
model. Serf functions are always called within a single thread
associated with serf_context_t, but the application can be
multi-threaded and have multiple contexts active in parallel. The
error callbacks will have no idea which thread it was called from.
Serf has very little global mutable data, I think only the recent
changes for registering authentication methods introduce global locks.
More locking == more opportunities for subtle errors.
I'm implementing error callbacks and found an "interesting"
circumstance. In ssl_buckets.c, where there was a ssl_context-specific
error callback, some error conditions were reported *only* if the error
callback was defined. Basically, not defining an error callback would
mean that some failures weren't noticed and things would just go
swimmingly on as if nothing happened.
I found this when I moved to a different callback model and an SSL test
started failing ... it turns out that the test has a bug and previously
"succeeded" only because actual errors were not being reported. What fun. :D
The core bug is of course not properly returning errors if some optional
callback wasn't defined. I've fixed this with the new callback code and
I'm now looking at how to fix the test, it's basically a test setup bug.
I want to make this a one-commit thing so that we can review the new
callback design with actual example code, and it's easy to revert if
necessary. If everyone's happy with how I decided to go about this,
there'll be more changes to come to get reporting from the ssl_context
hammered out and some tests added.
Just a few more minutes hours days now...
-- Brane
