Author pitrou
Recipients BreamoreBoy, dmalcolm, giampaolo.rodola, josiahcarlson, matejcik, pitrou, santoso.wijaya
Date 2010-09-25.11:56:47
SpamBayes Score 1.58723e-06
Marked as misclassified No
Message-id <1285415803.3192.9.camel@localhost.localdomain>
In-reply-to <1285415021.97.0.618894500609.issue6706@psf.upfronthosting.co.za>
Content
> The point of frameworks such as asyncore and twisted is to hide all
> system-specific errors as much as possible and provide a portable
> interface across all platforms.

As long as these errors are reasonably explainable.
If a strange error only occurs when running nmap on an OS X server, then
it might be useful for the user to know that the OS X server isn't able
to service all connections properly due to a bug in the operating
system.

> AFAICT, the whole point of this issue is that there should be only one
> way for an asyncore-based server to accept an incoming connection,
> possibly avoiding the user to deal with low-level details such as
> catching EWOULDBLOCK/ECONNABORTED/...

I am talking specifically about the address being None (i.e., a (sock,
None) tuple is successfully returned).
EWOULDBLOCK and ECONNABORTED are documented error conditions for
accept(), but returning 0 in addrlen is not.

> As I said, in a better designed framework the user shouldn't be
> supposed to call accept() at all, but that's how asyncore is designed.

Perhaps it's time to add an alternative handle_accepted(sock, addr)
which relieves the user from calling accept() :))
Then, perhaps self.accept() shouldn't filter any errors at all, but the
default handle_accept() would silence them before calling
handle_accepted().
History
Date User Action Args
2010-09-25 11:56:49pitrousetrecipients: + pitrou, josiahcarlson, giampaolo.rodola, matejcik, dmalcolm, santoso.wijaya, BreamoreBoy
2010-09-25 11:56:47pitroulinkissue6706 messages
2010-09-25 11:56:47pitroucreate