On Mar 14, 2008, at 8:49 PM, Jyri J. Virkki wrote: > Once upon a time Dag-Erling Smørgrav wrote: >> >> The poll code has seen very little maintenance or testing lately, >> simply >> because there are better alternatives on all the platforms we >> officially >> support. Theo Schlossnagle has an acceptor implementation that uses >> Solaris event ports; you may have more luck with that than with poll. >> >> In any case, thank you for the patch; I will commit it as soon as >> possible. > > While I'd meant it as more of an illustrative than final patch, I see > you massaged it during checkin already, so thanks! > > The other immediate problem I saw I've filed as ticket 222[1] and > included the patch there (related to IOV_MAX limit on Solaris, which I > see from the archives was discussed earlier and the define was > changed, > but didn't quite work). > > I realize the poll implementation isn't that interesting but I figured > I'd start with it as an initial experiment and add an event port > alternative later, but nice to hear it's been done. > > Theo, are you planning on contributing it to the main trunk to make it > easier to access and keep in sync?
Here's a more recent patch: http://lethargy.org/~jesus/misc/varnish-cache-2543-sol10-2.diff I'd love to have the changes put back. There are a few outstanding issues: 1) the ping/pong stuff (cross notify) is done to leverage the efficiency of event ports, but it is a bad hack from the integration perspective. I can fix this when I get some time -- don't have enough of that at the moment. 2) The socket timeouts aren't supported which is bad and nontrivial to fix. However, adding a very thin read(v)/write(v)/sendfile(v) abstraction layer would make this very easy and make the SSL featureset trivial to add as well. I could add this in if the developers are interested in it? 3) The VCL compiler stuff is changes to support a short-coming of the Sun Studio toolchain. And while the change should work everywhere, phk expressed some dislike for it. Apparently, it's a system("") call, so I could do some trickery by chaining commands to work around the issue. I think my work-around is more to-the-point. I doubt that will be taken back, which is fine -- it's subjective argument over which approach is better. 4) The IOV_MAX stuff is still an issue as the Sun Studio C preprocessor doesn't work with #if (IOV_MAX < (HTTP_HDR_MAX * 2)) Aside from those issues. The patch is working well for us in production. We've hit no issues with (2) at this point which is the only part that is bonafide technical problem. For 2) above, the approach I would take is to change the session fd to be an: typedef struct varnish_io_opset { int (*read)(void *op_ctx, void *buf, size_t nbyte); int (*write)(void *op_ctx, const void *buf, size_t nbyte); ... readv ... ... writev ... ... sendfile ... } varnish_io_opset_t; typedef struct varnish_socket { varnish_io_opset_t *ops; void *op_ctx; } varnish_socket_t; This would also obviate the IOV_MAX trickery as Solaris would get its own I/O opset. Best regards, Theo -- Theo Schlossnagle Esoteric Curio -- http://lethargy.org/ OmniTI Computer Consulting, Inc. -- http://omniti.com/ _______________________________________________ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev