[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: openlog
- From: Sean Conner <sean@...>
- Date: Thu, 15 Aug 2013 00:39:44 -0400
It was thus said that the Great Matthew Wild once stated:
> On 14 August 2013 05:02, Gary V. Vaughan <email@example.com> wrote:
> > Hi Matthew,
> > On Aug 13, 2013, at 8:29 PM, Matthew Wild <firstname.lastname@example.org> wrote:
> >> On 13 August 2013 14:13, dcharno <email@example.com> wrote:
> >>> The GNU libc manual says the pointer to ident in openlog is retained and the memory shouldn't be freed. I noticed the openlog binding in luaposix doesn't do anything special to make sure the string isn't garbage collected and neither do most FFI bindings for syslog. I haven't experienced a problem (yet) so maybe it isn't an issue. How do people handle this in their bindings.
> >> This is one of the reasons we're not using luaposix in Prosody yet. We
> >> use this code, which works for us so far:
> >> http://hg.prosody.im/trunk/file/e8c79796ead9/util-src/pposix.c#l163
> >> It would be nice to handle this well in luaposix.
> > I don't personally use all the calls available in luaposix, but I am very happy to apply patches to improve the parts I don't use myself… or even write patches for those parts if someone sends me a test (any smallish self contained Lua snippet is perfect!) that will verify my implementation is correct :)
> A year or two ago I evaluated luaposix, with a hope to switch Prosody
> to using it instead of our own little library. Ultimately it was a
> bunch of minor issues that put me off at the time. I had a small email
> exchange with Reuben Thomas at the time. I'll include a relevant
> section from one of my emails:
I've pretty much written my own wrappers for Posix functions , grouped
by what makes sense to me (files and directory APIs in one module; process
related functions in another; network related functions in a third, etc).
As for openlog(), right now I have to make sure that whatever I pass in
remains viable, but I see the solution you use and I think I'll be adapting
that as well.
> 1) Silly API decisions
> Minor on the surface, but makes the library and code using it just
> seem unnecessarily ugly. One example, getpid() returns a table. I see
> someone was trying to make it smart, but getpid("pid") just seems
> silly. Let's see about getuid()... oh, no, that's getpid("uid"),
> despite a uid not being anything like a pid. How about setting it?
> setpid("u", ...). Sigh.
> My approach would be to bind individual POSIX functions as tightly as
> possible, and only deviating when necessary to keep the interface to
> Lua clean and usable. It seems like the current API can't decide
> whether it wants to be high or low level.
That's pretty much the approach I took, except that I don't have a
getpid() function (org.conman.process.PID contains the current PID). But I
do have setuid(), setgid(), getuid(), getgid(), etc.
> 3) Error reporting
> In Prosody's POSIX library we have fixed error strings such as
> "permission-denied", which are more important than the
> locale-dependent human-readable strings given by strerror() (ideally
> we would have a function to return strerror() for any error name).
I handled that by setting the __index() method on org.conman.errno:
errno = require "org.conman.errno"
I also have (as far as I can determine) a predefined set of errors defined
in org.conman.errno so one can check for specific errors:
if err = errno.EINTR then
elseif err == errno.ETIMEDOUT then
I should also note that all of my Posix routines return errno as the second
result (if no error, then it returns 0). I'm consistent in this, because
consistency is good.
> 4) Documentation
> A big issue, especially with the current bizarre API - there's
> basically no way to use the library without reading the source, unless
> I've missed the documentation somewhere (I do find it hard to believe
> a library that has been around so long has none).
Alas, that's a problem I have ...