[Mono-dev] Replacement for Mono.Unix.UnixFile.TryReadLink
lupus at ximian.com
Thu Jan 12 10:40:16 EST 2006
On 01/11/06 Jonathan Pryor wrote:
> > > // 1.1.12 Code:
> > > string target = UnixFile.TryReadLink ("sym-link");
> > >
> > > // 1.1.13 Code:
> > > UnixSymbolicLinkInfo symlink = new UnixSymbolicLinkInfo ("sym-link");
> > > string target = symlink.HasContents ? symlink.ContentsPath : null;
> > Why is the first method obsoleted, though? It's way clearer and likely
> > faster, too.
> Because most of the UnixFile methods were forwards to UnixFileInfo
> members, so I removed it in the interest of simplification &
I'd say the simplification part didn't really work that well since now
3 method calls + conditional execution is required to do what a single
call accomplished before.
> I also doubt that it's significantly faster. The UnixSymbolicLinkInfo
> creation implies a stat(2) call that TryReadLink() avoids, but
> TryReadLink() didn't know how large a buffer readlink(2) required (which
> is stat.st_size), so it had to guess (and it guessed wrongly -- if the
> symlink was > 512 characters TryReadLink() would return null).
A buggy implementation is not an excuse for the slow performance
of a substitute.
First: the exisiting interface is so much easier to use that even if it
would be more expensive it is worth having. It is ironic that the
new solution is worse than the old one both in speed and code clarity.
The issue you point out about having to guess the buffer size is a red
herring: readlink(2) returns the number of bytes written, so a simple
check and loop is needed when the returned size is equal to the buffer
There is also an important factor to consider: even if the current
implementation of the method is suboptimal, it can be optimized
(and fixed for the case you point out).
The new implementation will always be slower and for no good reason.
lupus at debian.org debian/rules
lupus at ximian.com Monkeys do it better
More information about the Mono-devel-list