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:
>> On 08/24/2015 11:54 AM, Pavel Březina wrote:
>>> On 08/21/2015 07:01 PM, Nikolai Kondrashov wrote:
>>>> I might be in a strange and careless mood today, but here is something
>>>> wanted to suggest since the time I saw the amount of logic that goes
>>>> SSSD and is implemented in C.
>>>> What if we implement some of the complicated logic inside SSSD in Lua
>>> can you tell us what features of Lua do you like and might help simplify
>>> SSSD? I don't know the language, just fast scrolled over the manual and
>> Most of all, I like its simplicity, then flexibility. And then how easy it is
>> to embed. The latter comes from simplicity, first of all.
>> I listed the features I think will help us in the other message in this
>> thread, but here they are again and then some:
>> * exception handling
>> (somewhat rudimentary, but workable)
> This may be interesting, but we are pretty diligent I think, thanks to
> the tevent_req design pattern, at surfacing error
Main benefit of exceptions to me is not to have to propagate errors
>> * 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.
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.
>> * easier data massaging
>> (string operations, built-in (limited) regexes, etc.)
> We do some limited string manipulation but not really much, what other
> kind of data massaging does Lua provide that makes it worth ?
Well, can't think of many specifics, ATM, but let's say easier structure
creation for example. Just stuff data into tables in any place with a succinct
syntax. Especially useful for ad-hoc single-use structuring, where writing
constructor functions is not worth it, and allocating a structure and then
assigning fields in place is a pain.
Yes explicit memory management is a pain point in C, but in and on
itself does not justify changing sssd, so I'll discount this point under
the general "memory management is easier" argument.
>> * 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.
>> * 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.
> How does Lua work with asynchronous operations ? We have a ton
> 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
) would do what asynchronous tevents do.
If you mean OS threads, then there are several libraries that support
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.
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.
me knowing that it
>> has two pairs of equality operators  is quite off-putting.
> for anything security oriented.
Now, this is interesting. Care to elaborate? Is there anything really in the
The browsers just implement the language, which is quite awful.
>> There is, however, a seemingly good comparison, which should
give the general
> 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
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
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.
Simo Sorce * Red Hat, Inc * New York