Catch "Protocol wrong type for socket" on OSX also for non-blocking sockets

[Safihre]

This was originally fixed for regular sockets in cherrypy/cherrypy#1392
But it seems it can also occur during the sending on non-blocking sockets https://forums.sabnzbd.org/viewtopic.php?f=2&t=22728&p=112251

This is on our build-in CP 8.1.2, but since the code seems identical it can occur in any CP version.
Code section is now here: https://github.com/cherrypy/cheroot/blob/master/cheroot/makefile.py#L55-L63

[webknjaz]

Why just OS X?

[Safihre]

It's osx specific, just like the previous fix. It's all in the article that's linked from the previous fix: cherrypy/cherrypy@2ad0cb2

Summary: socket isn't ready yet, Apple made there own error code. Only happens from time to time.

[webknjaz]

Still it's not added to non-blocking error codes in that patch. Why?

[Safihre]

I have no clue, probably because the original author didn't experience it with non blocking ones. But as you can see from the linked issue on our forum, it does happen for non blocking ones.

[webknjaz]

Makes sense

[webknjaz]

Makes sense

[The-Compiler]

I'm the author of the original PR - I don't really remember, but I don't think it was deliberate that I didn't add it to the non-blocking ones. I probably just saw socket_errors_to_ignore and didn't even check what socket_errors_nonblocking was about 😉

[webknjaz]

Well, anyway it's going to be released in v5.5.1

[Safihre]

@webknjaz It seems this patch did not actually work, users are still reporting it.
Could it be that we are catching the wrong error type?

Traceback (most recent call last):
  File "cherrypy/wsgiserver/__init__.pyc", line 1412, in communicate
  File "cherrypy/wsgiserver/__init__.pyc", line 863, in respond
  File "cherrypy/wsgiserver/__init__.pyc", line 2342, in respond
  File "cherrypy/wsgiserver/__init__.pyc", line 2424, in write
  File "cherrypy/wsgiserver/__init__.pyc", line 916, in write
  File "cherrypy/wsgiserver/__init__.pyc", line 1050, in write
  File "cherrypy/wsgiserver/__init__.pyc", line 1057, in send
error: [Errno 41] Protocol wrong type for socket

It seems to be of the general error class. Is that a problem?

[The-Compiler]

@Safihre That stacktrace looks like you're still using an old CherryPy with wsgiserver integrated, and not cheroot.

[Safihre]

Yes but it has the same patches. Does not matter for the issue here.

[webknjaz]

@Safihre Since you're vendoring CherryPy you might've messed up with patching it.

[Safihre]

If you didn't spread cherrypy into 15 different (sub)dependencies, we could stay up to date with the latest patches instead of this.

[webknjaz]

Well, you still can: just use git submodules and keep patches in forks.
We needed to separate cheroot out of cherrypy, so that people who don't require cherrypy could just depend on cheroot.

[webknjaz]

@Safihre
This error is translated to code 91 under GNU/Linux. Have you tried this under OS X? Is it resolved to code 41 in Darwin?

In [1]: import cheroot.errors

In [2]: cheroot.errors.plat_specific_errors('EPROTOTYPE')
Out[2]: [91]

[The-Compiler]

FWIW I'm already only depending on cheroot without CherryPy, so I appreciate the separation 😉

@Safihre do you have a way to check whether you can reproduce this with a vanilla, up-to-date cheroot?

[Safihre]

My patch seems to work as it's supposed to.

>>> cherrypy.wsgiserver.plat_specific_errors('EPROTOTYPE')
[41]
>>> cheroot.errors.plat_specific_errors('EPROTOTYPE')
[41]

Very strange. Maybe something gets altered during the packaging process using py2app. This will take more time to investigate.

---

@The-Compiler @webknjaz
I wish it was just cheroot, but actually we have gone from:

• cherrypy

To

• cherrypy
• six (understandable of course)
• cheroot
• portend
• tempora
• pytz (as explained here Why the tempora dependency jaraco/portend#4, of course we need time-zone support when checking for open ports,...)
• jaraco.classes (assuming that Expose HTTPRedirect default status cherrypy#1611 gets merged)

We ship our software to over 100.000+ users. While for the packaged Windows/macOS we can use pip during the build and all would be fine, on Unix platforms we need to bundle the exact versions otherwise the platform package managers like Debian/Ubuntu might have older versions of each that don't match what we or cherrypy-package needs.

In the end it's all open-source and who am I to complain really?
Cherrypy provides us with a great and easy tool to handle our interface.
This is just to explain why we stick to 8.1.2.

[webknjaz]

@Safihre

Alright, I think it's better to create a separate issue with your findings once you investigate your packaging and maybe find smth interesting.

Meanwhile I still feel that there is more flexible way to vendor cherrypy with its dependencies. Maybe you could even use installation bundles or run simple pip install --no-binary :all: --target . --src . git+https://github.com/cherrypy/cherrypy#egg=cherrypy before building binary in your CI.
If you decide to follow my advice, feel free to create an issue for investigation of bundling techniques and I'll try to help you with that. My vision is that this might help you with your patches and syncing w/ upstream.