select() errors and AnyEvent::Loop

[Felipe Gasper]

> On Jul 1, 2021, at 3:01 PM, Marc Lehmann <schmorp at schmorp.de> wrote:
> 
> What might be confusing is that AnyEvent isn't meant to be an educational
> tool nor a fluffly learning environment, but be as performant as possible
> while being correct - supporting debugging or broken programs is not a
> (priority) goal.

FWIW I don’t consider throwing away useful failure messages to be correct behaviour, and I daresay few would. The only select() failure state I can see being useful to ignore here is EINTR; any other from select() indicates a problem that should be fixed--even if that problem is as benign as a second or two of tight-looping.

I’ve found that “fail early and often” yields an overall more satisfying result than trying to coerce a useful state out of a faulty one. That said, it wouldn’t be AE’s (or AE::Loop’s) place to dictate that to a caller.

> 
>>> I don't see how "throwing" would make the problem more easily identified.
>>> Certainly, "throwing" is unlikely to be correct for _any_ program?
>> 
>> In a “happy-path” scenario, sure, but when errors happen it’s nice IMO to report them rather than discarding them. Yes, it’s the calling program that needs to be fixed, but it’s much easier to do that if the called library helps out.
> 
> The called library already helps out in this any many other cases,
> and different event implementations can also help out (e.g. libev has
> loop->verify). There will always be limits to this, though, and we have to
> draw the line somewhere.
> 
> In any case, since you are asking to crash potentially working and correct
> prorgams for the benefit of incorrect ones, I think this is a bad change
> to make, but of course you can patch your version locally, which might be
> a good idea since you don't have to support (officially or not) programs
> other than your own.

To clarify: I recognize (now, today, having looked at this further) that a general throw-on-failure would be prohibitively disruptive behaviour. A throw-on-failure-with-no-timer would not be, but as you observe, a “helpfulness” line is to be drawn somewhere. So hey.

Anyhow, thank you for your responses. Take care, and thank you again for maintaining this and so many other important CPAN modules.

-FG