Re: [Lcd4linux-devel] plugin_mysql, to do list.

[Martin H. <ma...@he...>]

Hi Xavier,

>>- lcd4linux will stay pure C (as the linux kernel does)
>>- lcd4linux will not use any threading library, the places where 
>>asynchronous execution is necessary are rare and will be solved using 
>>traditional fork() and shmem.
> 
> In fact to aswer to Martin, C++ threads are less memory-wasting than
>   the C fork(), as fork copy the whole process, with its variable and
>  others.
I'm very well aware of the difference between multi-threading and 
multi-processing. But IMHO your assumption is wrong, unless Linux 
nowadays works completely different from what I've learned in the past. 
Unless you change a variable, fork will reserve, but not actually use 
any of that address space. Besides, by "memory footprint" I was actually 
more referring to the almost 3MB large libstdc++.so that comes with 
using c++. I couldn't really care less if there's another 500k process 
running (at runtime) - but adding 3 MB in libs (which need to be saved 
on the install medium - which _may_ be a floppy, for my target 
plattform) surely is an issue for me. Especially so, if it's done so 
without a huge benefit.

> I don't know what you think about it, but maybe we can fork very early
> in 3 threads: main, plugins, and soon input to make all these work
> asyncronously and solve many problems we'll encounter with input. But
> this will surely lead to problems with shared variables and other.
> 
> Do as you want Michael, but IMHO slitting into 3 (by now 2) threads
> would be "proper". But we'll be able to troll about this after 0.10.0 is
> released. ;)
I don't think this is so much about "style", but rather about keeping 
the code maintainable. Forking and using IPC is something that works, 
and has been working for ages (even if it's not the most efficient way, 
and even if threads could do it better - lets be honest, we're not 
talking about megabytes of data per second being transferred between 
those processes). So, it's something that people are comfortable with, 
something that doesn't change anymore (unlike the threads API - or so I 
gather from the problems that came with the introduction of nptl), so it 
sounds like the way to go, as long as we don't have something that needs 
to move tons of data (IPC is relatively slow, afterall) and that isn't 
too time-critical.

I don't really see what we'll gain by limiting ourselves to 3 processes 
(or "threads" if you prefer those) - to me, every plugin should be able 
to create its own data-gatherer thread if it needs one.
If we go your route, it will only make the "plugins" process very 
complicated (since it needs to play scheduler), none of the functions 
may block, or other plugins will be blocked too, that kind of thing.

My suggestion (and that's the way I understood Michael as well) is to 
use a "worker process/thread" for each plugin that will be slow/may 
block. Memory consumption is not so much an issue, since most of it will 
be marked as "shared" anyway, so memory usage on the box will only 
increase marginally.

>>What about plugin_wifi? Martin will neeed it, IIRC.
> 
> I began to write it last week while recompiling a 2.6.3 kernel on a
> 133MHz notebook (so I had time to code :D ), it was a mere copy of
> plugin_netdev.c as the two files /proc/net/dev and /proc/net/wireless
> are similar, but I found a syscall to retreive the informations, 
A syscall? Care to explain? All I know so far is that the wireless 
extensions API works via IOCTL calls - I never heard/read of syscalls 
for that in the past (maybe this is simply about a different definition 
of "syscall" - to me, a "syscall" is a function exported by the kernel - 
whereas an IOCTL call is a specific syscall, that takes specific 
parameters (and those parameters tell it what to do)).

> I have to dig more about this function and write the
> plugin --> added to my ToDo :)
So, you _are_ working on that (or did you just add it to your ToDo 
list)? Don't get me wrong - I just want to make sure we don't duplicate 
work (and still get a working wifi plugin in a timely manner). I've 
added plenty of things onto my ToDo list in the past (which I never 
completed), so I want to make sure :-)

Martin