Date: Mon, 14 Jun 2004 05:28:35 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Brian Feldman <green@freebsd.org> Cc: ports-committers@freebsd.org Subject: Re: cvs commit: ports/sysutils/cdrdao Makefile distinfo ports/sysutils/cdrdao/files patch-Makefile.in patch-configure patch-dao::ScsiIf-lib.cc patch-dao::cdrdao.drivers patch-dao::dao.cc patch-paranoia::isort.c patch-trackdb::Track.cc patch-trackdb::lec.cc ... Message-ID: <20040614052835.I1600@newtrinity.zeist.de> In-Reply-To: <20040614021442.GB39574@green.homeunix.org>; from green@freebsd.org on Sun, Jun 13, 2004 at 10:14:42PM -0400 References: <200406131501.i5DF1Sqm065546@repoman.freebsd.org> <20040614021442.GB39574@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 13, 2004 at 10:14:42PM -0400, Brian Feldman wrote: > On Sun, Jun 13, 2004 at 03:01:28PM +0000, Alexander Leidinger wrote: > > - Disable the use of mlockall(2) on FreeBSD 5, even after the last round > > of fixes there are still issues. > > What are you referring to? The issues that are still there should not > affect simple mlockall(2) usage. > - On i386, depending on the program, mlockall() always returns EAGAIN. E.g. ntpd of the net/ntp port exhibits this problem. This isn't an issue with cdrdao. - On sparc64, every call of mlockall(MCL_CURRENT) returns EAGAIN, even in a program just doing that. Don't know about the other architectures. So there is no technical reason to not to use mlockall() as it no longer seems to have side effects (at least not on i386 and sparc64) like random processes crashing when another one uses it or causing panics like it did in the beginning. But I don't want to frighten the users of a port with the warnings that the failing mlockall() causes, especially if it is a verbose one like that of cdrecord.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040614052835.I1600>