On 09/24/2012 02:16 PM, Richard W.M. Jones wrote:
On Mon, Sep 24, 2012 at 02:07:36PM -0600, Eric Blake wrote:
> On 09/24/2012 01:53 PM, Richard W.M. Jones wrote:
>
>>>> + /* Search for the name in the existing environment. */
>>>> + namelen = strcspn(env, "=");
>>>
>>> Would 'strchr(env, '=') - env' be any more efficient? But
that's a
>>> micro-optimization, probably not worth worrying about.
>>
>> I guess I trust glibc or gcc to have these string primitives
>> optimized better than I could.
>
> Ah, but glibc is open source, so we can check for ourselves:
> That is, you are definitely wasting time pre-computing the reject
table,
> compared to doing a strchr() for the one rejection.
http://sourceware.org/bugzilla/show_bug.cgi?id=14613
Possibly, if we weren't just about to spend 100000 cycles doing a fork.
Now, a project to rewrite all Python utilities in Linux in a compiled
high-level language like OCaml, there's something I could get behind :-)
Precisely why I said it is a 'micro-optimization, not worth worrying
about in this context' :)
Unfortunately this patch does not fix the bug, but it now
fails in a different, and stranger way:
libvir: error : libvirtd quit during handshake: Input/output error
In this code:
if ((rv = saferead(cmd->handshakeNotify[0], &c,
sizeof(c))) != sizeof(c)) {
if (rv < 0)
virReportSystemError(errno, "%s",
_("Unable to wait on parent process"));
else
virReportSystemError(EIO, "%s",
_("libvirtd quit during handshake"));
return -1;
}
Ewww. Something went wrong in the child, which in turn messed up the
handshake notifier. Can you set up gdb to follow the child after fork,
and see why the child is going haywire?
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org