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