Date: Wed, 23 Jul 1997 07:41:00 +1000 From: David Nugent <davidn@labs.usn.blaze.net.au> To: Andrew Gordon <arg@arg1.demon.co.uk> Cc: Michael Smith <msmith@atrad.adelaide.edu.au>, freebsd-hackers@freebsd.org Subject: Re: utmp/wtmp interface Message-ID: <199707222141.HAA00327@labs.usn.blaze.net.au> In-Reply-To: Your message of "Tue, 22 Jul 1997 17:28:42 %2B0100." <Pine.BSF.3.91.970722172644.2234A-100000@server.arg.sj.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Absolutely it is, and the penalty is paid by the non-threaded > > > version, and it makes the code more complex then it need be in > > > any case. The point is whether there is any benefit in making it > > > thread-safe. :-) > > > > Good question. Maybe save worrying about that until it needs to be? > > But isn't the time of definition of the API the only chance to do it > cheaply (ie. by having the caller pass in all required buffers, > avoiding the need for static buffers in the library)? Ok, can you suggest an alternative interface which does that, avoids being 'messy' (like avoiding long parameter lists or passing obscure structs etc), isn't going to cause a significant problem with performance, and doesn't come up against limitations if the called-supplied buffer is not large enough? If you missed it, the code being discussed is at http://www.freebsd.org/~davidn/utmpwtmp/libutil-new.tar.gz. I'd be delighted to look at suggested alternatives which are a lot more concrete than suggested based on general principles. Context or unified diffs against that would be wonderful. I said right here (or in -current, don't recall which precisely) after I had started it that I was not happy with memory management, and using a static buffer seemed to be the only way I could do this cleanly without overly-complicating the API itself. This uses static data in precisely the same way that, for example, getpw*() and getgr*(). I don't much like the style of those interfaces either for exactly the reasons we are now discussing, but these are traditional APIs. The difference, however, is that this is libutil, not libc. We don't yet have a libutil_r, and it'd be nice if we could avoid having one at all. > Qpologies if I've missed the point here. No qpologies (sic) necessary. :-) BTW, apologies to Michael for misunderstanding his previous post on this. His suggestion, I realised later, regarding the 'self- describing format' as he calls it, applied to utmp, not wtmp as I had thought at the time. Yes, once we get to it, this wouldn't be a bad way to go, although I still think this would probably be overkill. The point here isn't so much to redefine the file format (now), but to make it possible later. Perhaps some general ideas like these should be raised now so that we can at least allow for possible extensions in the API. Regards, David -- David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707222141.HAA00327>