On Tue Nov 16 22:00:58 2010, POWERMAN wrote:
Show quoted text> On Tue Nov 16 20:40:39 2010, ATHOMASON wrote:
> > Unless I'm missing something, a single retry is exactly what you're
> > proposing.
> I've proposed single _blocking_ retry call.
> But I got your point now, and it have sense, thanks.
>
> Probably your implied policy have to be documented. Actually, current
> documentation doesn't match that policy:
>
> 1) METHODS - new() - $proto states $logger->send() will block for
> LOG_UNIX
> 2) UNREACHABLE SERVERS - LOG_UNIX doesn't mention raised exception on
> EAGAIN, and that's only place where exceptions documented.
Oh, this is about LOG_UNIX? I just assumed you were using LOG_UDP since
that's the only one that's configured to be non-blocking (see
https://github.com/athomason/Log-Syslog-Fast/blob/master/LogSyslogFast.c#L143).
AFAIK LOG_UNIX should never have an EAGAIN error since send(2) is only
supposed to return that for a nonblocking socket. Do you have a test
case showing that behavior?
Show quoted text>
> BTW, I'm using only non-blocking I/O for years in nearly all projects,
> so I understood your needs, but don't 100% agree with proposed
> solution. In event-loop based applications with non-blocking I/O it's
> usual to have all sockets managed by epoll()-like thing. There usually
> some low level engine, which control _all_ sockets, automatically
> handle EAGAIN, keep outgoing buffers for all sockets, etc. So, if you
> design your logger module for such environment it have much more sense
> to provide some way to delegate managing of log socket to same low-
> level engine used in user's application (like EV or AnyEvent modules).
> And throw exception/send error event to user only when buffer is full
> or something like that, not on every EAGAIN.
Indeed, that's what something like Log::Syslog::DangaSocket is for
(using the Danga::Socket epoll-based event loop). The assumption in
L::S::Fast is that use of the unreliable UDP transport goes with a
desire for "fire and forget" logging.
Show quoted text>
> IMHO handing EAGAIN on user level is just plain wrong in such
> applications - that's too low level thing, it require complex enough
> handing (especially when log socket doesn't delegated to epoll and user
> can't just get event notification when socket will be ready to accept
> more data), and there not much things user can do with this.
There's not much the module can do either; the "right" behavior on
failure depends on the application. In the frequent case where the retry
fails as well, the policy decision needs to be made again. But that
decision should be at a higher level; not necessarily as high as the
client code, but possibly as a subclass which overrides send() to handle
retries.
