PDCLib design question

[kataklinger]

Sorry, Google gave me strange resaults when I searched first time :-[

[Candy]

Google, dlmalloc, first link. ::)

hm... within 5 seconds from another. that's pretty amazing

[srg]

I've voted for the dlmalloc().

One thing I have found with it and portability with different processors is that there is one or two lines of inline assembly in it. These of course would need to be recoded for each architechture.

[Solar]

I'll see how hard / easy adapting dlmalloc() is. If it turns out to be holding me up, I'll probably write up a "barebones" (e.g., first-fit, don't-care-about-fragmentation) malloc() to get going and return to it later.

It's just that I feel like it's cheating.

PDCLib v0.4 will contain a malloc() / free() that:

• uses a single-linked-list of free memory chunks,
• does an exact-fit / first-fit on free chunks,
• requests a number of extra pages from the system if both fail,
• does join adjacent memory chunks in the free list to reduce fragmentation,
• but never returns memory to the system.

The implementation is primitive, but was quickly done. I'll return later for a full-fledged production-grade implementation.

I still feel like I'm cheating, here. I'm also reluctant to release such a primitive solution to the CVS. But I'm eager to get the remaining basics (stdio.h) covered ASAP before starting the "hard work" (math.h, locales / wide char support, production-grade malloc() ).

Thanks for voicing your opinions, I appreciate the feedback.

[Solar]

Shamelessly bumping this thread.

v0.4 has just been released, including the memory management functions. No defragmentation, no releasing of memory back to kernel. Both could be added with a couple of lines, and efficiency could be much improved, but those are placeholders only as discussed above.

I'll focus on another project for a while, and return to PDCLib after that is done. (Breakpoint 2006 at the very latest.)

Next on the menu: stdio.h.

[Solar]

Me again. (I'll just reuse this thread instead of spawning a new one whenever I have a design question. )

Regarding <stdio.h>: There is this thing with unbuffered output. stderr, for example, or streams explicitly set to unbuffered with setvbuf(). My question is regarding the printf() functions - it would be possible to have them print each individual character as soon as it comes out of the conversion functions. The faster option, of course, would be to print the whole shebang in one go right before printf() returns - but it wouldn't exactly be unbuffered...

What do you think? (The lib is mainly for you folks here, after all...)

[octavio]

My printf implementation uses sprintf function wich uses a buffer.Printing one character at a time would have a performance problem.About the malloc, the single list algo has less fragmentation but is too slow(inaceptable for some aplications), using a array of lists is very fast but has more fragmentation.

[Solar]

Yeah... I was more talking about the printf() function family. In the end, they're all frontends to vsnprintf() of course. And of course is unbuffered output slower than buffered one, but the standard provides _IONBF for streams, which explicitly advertises that "characters are intended to appear from the source or at the destination as soon as possible"...

Re malloc(), that one has been decided - single list while it's all (pre-) alpha, and a dlmalloc() adaption later on.

[Candy]

Yeah... I was more talking about the printf() function family. In the end, they're all frontends to vsnprintf() of course. And of course is unbuffered output slower than buffered one, but the standard provides _IONBF for streams, which explicitly advertises that "characters are intended to appear from the source or at the destination as soon as possible"...

Re malloc(), that one has been decided - single list while it's all (pre-) alpha, and a dlmalloc() adaption later on.

I would bend ASAP to ASAPP -> "as soon as possible" ... "as soon as practically possible". I would consider the flag to be more of a "when this thing completes, all characters must be at their target". That case, it doesn't matter whether you buffer it internally or not.

[df]

Im writing a printf for a new project (my own), and I send a string with length to a function so that func can do whatever, write it byte by byte or as one chunk. I dont use sprintf or any other func, so its all 100% standalone. (well it requires stdarg)...

there is noting in the printf spec that says on error nothing should be printed, so it is correct(ish) to partial print a string and hit an unknown/bad identifer (say: %K) and return -1... (mm ambiguous specs.....)...

[Solar]

Im writing a printf for a new project (my own), and I send a string with length to a function so that func can do whatever, write it byte by byte or as one chunk.

My idea was as follows: In the FILE structure of a stream, you usually have a pointer to the I/O buffer of that stream. So, any fprintf() call on that stream could be replaced by a sprintf() call on the I/O buffer of that stream.

The problem is that unbuffered streams don't have to have a buffer (obviously). Add to this that the sprintf() function has no idea how large the buffer is, and that exceeding the buffer size isn't really an error condition (as it would be in snprintf())...

I think I will issue individual putc() calls. putc() knows about the stream's buffer size, it knows if and when the buffer has to be flushed, and it can be a macro (i.e., efficient).

I dont use sprintf or any other func, so its all 100% standalone. (well it requires stdarg)...

Well, PDCLib will offer the whole shebang, but in the end all of them are just wrappers for the central conversion function.

there is noting in the printf spec that says on error nothing should be printed, so it is correct(ish) to partial print a string and hit an unknown/bad identifer (say: %K) and return -1... (mm ambiguous specs.....)...

The spec is very clear: "If a conversion specification is invalid, the behavior is undefined". I usually threaten to format the hard drive to make people realize what "undefined" really means.

[Candy]

What would printf do on this:

Code: Select all

printf("abc%sghi%smno\n", "def", (char *)0xDEADBEEF);

would it print "abcdef", "abcdefghi", "" or what? Also, when segfaulting, did it flush before, during, after, when catching the null pointer or anything?

[df]

I dont use sprintf or any other func, so its all 100% standalone. (well it requires stdarg)...

Well, PDCLib will offer the whole shebang, but in the end all of them are just wrappers for the central conversion function.

i guess you already have one but when i said it was standalone i meant it could be added to pdclib. but it sounds like you have one (im writing mince because i didnt find one in pdc 0.4)

[Solar]

What would printf do on this:

Code: Select all

printf("abc%sghi%smno\n", "def", (char *)0xDEADBEEF);

[tt]abcdefghi[/tt]{whatever is at 0xDEADBEEF until the next zero byte}[/tt]mno\n".

Also, when segfaulting, did it flush before, during, after, when catching the null pointer or anything?

Which segfault? Which null pointer?

[Solar]

i guess you already have one but when i said it was standalone i meant it could be added to pdclib. but it sounds like you have one (im writing mince because i didnt find one in pdc 0.4)

<stdio.h> is what I am aiming at with v0.5. I'm working on the printf() equivalent as we're talking.

@ Candy:

Why aren't you at Bingen?