Does Hunchentoot still need lispworks specific code?
Closed this issue · 4 comments
In theory usocket+bordeaux-threads should work fine on Lispworks. I use both Lispworks and SBCL, and have some code which doesn't work under LW (basically: restarting the lisp process while keeping the socket connection open by reusing the socket fd, but the exact detail is irrelevant).
It looks like Hunchentoot was initially created for LW, and then ported to other CLs with usocket, would it be a good idea for maintenance to completely remove the Lispworks checks? I'll be happy to make the changes and test it if people think this is a good idea.
Also, if somebody does want to use the LW stack, they could create a separate library with a custom acceptor. But personally, I can't think of any reason that might be useful.
I made a patch for this locally, and it mostly works, except for this bug: usocket/usocket#61 (at some point the socket read/write errors with EAGAIN). There's also some misbehavior with error handling that I haven't completely pinned down yet.
I can do the suggested patch on that task on usocket and everything works again. I don't completely understand this though, so I need to debug it further and make sure I know exactly what's happening before I can recommend this switch.
I don't use lispworks, so I don't want to break something people may rely on.
@stassats Fair enough, but I do use Lispworks, so I'm happy to do the testing. I think removing all the Lispworks checks will also make it less intimidating for developers to send pull requests, since most developers don't have the ability (or motivation) to check against Lispworks. Without Lispworks there'll be barely any feature checks in the code base, and all the complexity will be handled by usocket+bt.