gnokii-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 7/8] Use posix_spawn to run external scripts


From: Ladislav Michl
Subject: Re: [PATCH 7/8] Use posix_spawn to run external scripts
Date: Mon, 3 Dec 2018 17:00:42 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, Dec 03, 2018 at 06:28:56PM +0300, Pawel Kot wrote:
> Hi,
> 
> On Mon, Dec 3, 2018 at 12:54 PM Ladislav Michl <address@hidden> wrote:
> >
> > posix_spawn specification dates back to last century and its
> > implementation is mature enough in all systems we do support.
> > Thus use it instead of current fork and exec in hope it will
> > save us some resources.
> 
> There is more than this in this patch. Would you mind in splitting it into
> two or more parts?

Sure, no problem. I read above you are fine with that approach in general.

> A large portion of the patch is related to reorganizing
> the code. Two examples below.
> 
> Cheers,
> Paweł
> 
> > diff --git a/include/gnokii-internal.h b/include/gnokii-internal.h
> > index c4f6d625..9af2d8cc 100644
> > --- a/include/gnokii-internal.h
> > +++ b/include/gnokii-internal.h
> > @@ -20,6 +20,7 @@
> >  #ifndef _gnokii_internal_h
> >  #define _gnokii_internal_h
> >
> > +#include "cfgreader.h"
> 
> I think I was trying to avoid that for a long time. Not sure now about the
> reasoning.

I saw something like that in one of your commit logs... and therefore
will avoid that in next version.

However it would be nice if someone could actually give pachset a try.
Preferably on non linux platforms.

> > -typedef void (*cfg_foreach_func)(const char *section, const char *key,
> const char *value);
> > -void cfg_foreach(const char *section, cfg_foreach_func func);
> > +#define cfg_foreach_entry(section, header, entry) \
> > +       for (; header != NULL; header = header->next) \
> > +               if (strcmp(section, h->section) == 0) \
> > +                       for (entry = h->entries; entry != NULL; entry =
> entry->next)
> 
> Why that?

If that question leads to opencoding that single macro use, I'm fine
with that.

> Cheers
> Paweł

Best regards,
        ladis



reply via email to

[Prev in Thread] Current Thread [Next in Thread]