[SSSD] Embedding Lua into SSSD

Simo Sorce simo at redhat.com
Wed Aug 26 14:23:36 UTC 2015


On Wed, 2015-08-26 at 16:10 +0300, Nikolai Kondrashov wrote:
> On 08/25/2015 10:19 PM, Simo Sorce wrote:
> > On Tue, 2015-08-25 at 21:26 +0300, Nikolai Kondrashov wrote:
> >> On 08/25/2015 08:48 PM, Simo Sorce wrote:
> >>> On Tue, 2015-08-25 at 16:14 +0300, Nikolai Kondrashov wrote:
> >>>>        * automatic memory management
> >>>>          (incremental mark-and-sweep with good controls, customizable allocator)
> >>>
> >>> This is not really interesting as we already have talloc that does a
> >>> great job at keeping track of memory allocations and cleanups (esp if we
> >>> stop using the anti-pattern of allocating on NULL as discussed a few
> >>> times already).
> >>
> >> You still need to do it explicitly and think about it. Not that much, of
> >> course, and it's not that you don't have to think about it with a
> >> mark-and-sweep GC at all.
> >
> > I think a GC would be a regression to be honest,for the usage pattern of
> > SSSD a hierarchical allocator makes better use of memory.
> 
> I agree, memory can be used more efficiently with a hierarchical allocator.
> However, is saving memory a priority over lowering complexity for providers?

It is important, yes, because this is a system service that always runs
on the machine. We cannot explode the memory requirements or it will
negatively affect the whole system, we are already borderline for some
use cases.

> >>   Still, in the majority of cases you don't have
> >> to think about it, and you certainly don't have to assign memory to contexts
> >> and keep them, nor pass them around.
> >
> > True, but then you do not ever think of memory allocation with usually
> > comical situations where you leak tremendous amounts of memory because
> > you keep some reference mistakenly. Once that happen finding out what is
> > happening and reviewing every single variable allocation to find out
> > what is going on is generally extremely hard. It's a trade off really.
> 
> Agree. Doesn't happen often, though. In fact, I can't remember it happening to
> me. I had some difficulties bridging Lua and a C library (ClearSilver) memory
> management, but it wasn't Lua's fault and it worked in the end.
> 
> >>>>        * brevity
> >>>>          (implicit dynamic typing, syntax sugar)
> >>>
> >>> brevity is good for long-winded functions indeed.
> >>
> >> Well, it kind of works all through the code.
> >
> > Sometimes the brevity of scripting languages is obtained through
> > extremely inefficient code, with potentially unwanted side-effect (esp
> > wrt memory management). So it is not better in general, it is better for
> > the specific goal of making long functions more readable.
> 
> Sure. We can only consider it better or worse in isolation from other factors.
> 
> >>>>        * OOP support
> >>>>          (there are several libraries to choose from)
> >>>
> >>> This may be good or bad, it all depends on what you need to do.
> >>
> >> Sure. Although having something is better than not having, theoretically.
> >> Except diseases, of course :)
> >
> > As you see, sometimes having "something" is worse. For software that
> > works at lower levels OOP usually makes for software that is harder to
> > debug, so it may be an anti-feature.
> 
> Sure. OOP might only be useful for higher-level logic, but I don't suggest we
> use it otherwise. It was just a point that might help us.
> 
> >>> How does Lua work with asynchronous operations ? We have a ton of that
> >>> and unless Lua has native support it would be a huge mismatch.
> >>
> >> Now this is a good question. It depends on what you mean. If you mean central
> >> loop with state machines underneath, then coroutines is an awesome solution.
> >
> > It is not clear to me that Lua's coroutines
> > (http://www.lua.org/pil/9.1.html) would do what asynchronous tevents do.
> 
> I'll try marrying them when I have time and we'll see.
> 
> >> If you mean OS threads, then there are several libraries that support it,
> >> AFAIK. I haven't looked into them though.
> >
> > No, I do not mean threads, in fact sssd is not thread safe. I mean I/O
> > based events where a socket file becoming readable makes the chain of
> > nested events keep going on until the innnermost completes it's work and
> > data is returned (potentially massaged all the way back) to the
> > outermost event. With control returning to the main loop every time an
> > I/O operation would block.
> 
> Ah, good, I was worried we might need threads.
> 
> >> We'll have to try it to really know. If you can give me an example, I can try
> >> thinking about it.
> >
> > Look at how tevent_req stuff works / see above.
> 
> I will, thank you.
> 
> >>>> I don't know enough JavaScript to really compare, but to me knowing that it
> >>>> has two pairs of equality operators [1] is quite off-putting.
> >>>
> >>> I hope it doesn't compare much because javascript is awful, especially
> >>> for anything security oriented.
> >>
> >> Now, this is interesting. Care to elaborate? Is there anything really in the
> >> language itself and not the browser parts? Not that I like JavaScript myself,
> >> just curious.
> >
> > The browsers just implement the language, which is quite awful.
> 
> Well the fact that a browser would implement a scripting language is not that
> bad, IMO, but the huge mess of the DOM and the APIs is what makes it very hard
> to contain.
> 
> I would never suggest we put a browser, or DOM into sssd :)
> 
> >>>> There is, however, a seemingly good comparison, which should give the general
> >>>> idea:
> >>>>
> >>>>        http://stackoverflow.com/a/1022683/1161045
> >>>
> >>> To be honest a Javascript to Lua comparison doesn't really help much
> >>> understanding if Lua could be an asset for SSSD or not.
> >>
> >> Sure, I was answering the specific question from Pavel of how it compares to
> >> JavaScript.
> >>
> >> I think a lightweight embeddable language could be an asset to SSSD, in
> >> general. It doesn't have to be Lua. I think Lua is a good candidate, but there
> >> are other similar languages around, although probably not of such extended
> >> vintage.
> >
> > If we needed an embeddable language Lua would probably be a very good
> > candidate, it is not clear to me that the proposition adds enough value.
> >
> > We'd really need to see an example albeit small of how, some task
> > currently done in sssd would translate in Lua, with which tradeoffs.
> 
> Alright, I'll try to provide one, if even just for the fun of it, but it
> won't be soon.

Sure, np, thanks.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the sssd-devel mailing list