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?
> 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.
Thank you!
Nick