Re: libpager multi-client support

[Richard Braun]

On Tue, Oct 18, 2016 at 01:56:48PM -1000, Brent W. Baccala wrote:
> Can it be done in C?  Sure.  But following my principle of asking how to
> write the code in the simplest manner, this one is obvious: STL containers
> win.

I'm not saying it can't be done. I'm saying it's not that hard.

-- 
Richard Braun

Re: libpager multi-client support

[Brent W. Baccala]

On Tue, Oct 18, 2016 at 2:37 AM, Richard Braun  wrote:

>
> From my fifteen years or so experience working in various projects with
> C++ and other languages, my opinion is that C++ is never the best
> choice. It makes you trade lines of code for increased complexity in
> understanding and following the code. You should either go with C for
> excellent control, or another higher level langguage for e.g. user
> interfaces and tasks that don't require the highest performance.
>

My opinion is that C++ features have to be used very, very judiciously to
avoid the problems you describe.  It's very easy to fall into a "C++
mindset" and try to write everything in "C++ style".  My solution has been
to look at each problem and ask myself how to write the code in the
simplest manner.


> I really don't think the problem you describe would be so hard to solve
> in C.
>

Well, let's see.  To handle arbitrary numbers of clients, we have to
dynamically allocate all those queues and lists.  We have to copy them when
adding new clients or removing old ones (more dynamic allocation).  To
constrain memory utilization, we have detect when they're no longer used
and deallocate them.

Can it be done in C?  Sure.  But following my principle of asking how to
write the code in the simplest manner, this one is obvious: STL containers
win.

agape
brent

Re: libpager multi-client support

[Richard Braun]

On Mon, Oct 17, 2016 at 09:51:41PM -1000, Brent W. Baccala wrote:
> What do you guys think?

>From my fifteen years or so experience working in various projects with
C++ and other languages, my opinion is that C++ is never the best
choice. It makes you trade lines of code for increased complexity in
understanding and following the code. You should either go with C for
excellent control, or another higher level langguage for e.g. user
interfaces and tasks that don't require the highest performance.

I really don't think the problem you describe would be so hard to solve
in C.

-- 
Richard Braun

Re: libpager multi-client support

[Brent W. Baccala]

Aloha -

I've been thinking more about the data structures involved with the new
libpager code, and they're complex enough that I'd like to write them in
C++11.  The pagemap has to contain a list of all clients with copies of a
page, and a queue of clients waiting to access the page.  To keep the
memory footprint under control, the pagemap itself should be an array of
pointers to structures that are reused if multiple pages have the same
"clientèle", so they also need a usage counter, plus we need to make copies
of them (say, when a new client is added), which requires making copies of
their constituent lists and queues.  STL containers and shared pointers
seem like a good choice.

C linkage allows backward compatible use of the library.

The biggest drawback that I see is that memory usage might get out of
hand.  A std::shared_ptr, for example, is four times bigger than a regular
pointer.  After reading http://gamedev.stackexchange.com/questions/268 I
think it might not be so bad, but I'm not thrilled about it, either.  We're
basically paying for code simplicity with memory.

Also, programs like ext2fs would be linked against the standard C++
library, but I don't know if that's really such a problem.

Obviously, introducing C++ into libpager would probably open the door to
large scale use of C++ in Hurd.  This might not be such a bad thing.  I
suspect that serialization of RPCs could be done with templates,
eliminating a lot of the need for MIG.

What do you guys think?

agape
brent