IntenseDebate - Jeff Preshing

3 years ago @ Preshing on Programming - How C Resolves a Fun... · 0 replies · +2 points

You're not doing anything wrong. It's just not a complete program, since the definition of galaxy::blast isn't given.

3 years ago @ Preshing on Programming - How C Resolves a Fun... · 0 replies · +2 points

Thanks! The diagrams were made in Inkscape.

3 years ago @ Preshing on Programming - I/O in Plywood · 1 reply · +2 points

Right now the underlying pipe is closed in the In/OutStream destructor. But I'm open to adding a close() member function (or equivalent) if it exposes useful new functionality. (Everything in Plywood has been implemented on an as-needed basis so far.)

I'd like to understand the problem you're describing a little better. Can you give an example of a bug that you want to be able to avoid?

3 years ago @ Preshing on Programming - I/O in Plywood · 0 replies · +2 points

Hmm, I'll admit that when I replied, I was thinking about readers (InStream), even though your original question first mentioned StringWriter.

I think you're right about StringWriters. When the application writes text to a StringWriter, it's providing all the source string(s), and so the I/O system *could* convert directly from the source string to the temporary output buffer. At least for newline conversion (let's say).

This would change the API for StringWriter to some extent, and we would have to reserve a few bits from InStream::status to indicate what kind of newline conversion is performed by the StringWriter, but I think it would work. So that might not be a bad suggestion. I'm still not sure it would be easy/worthwhile to eliminate one of the buffers in the StringReader case though.

3 years ago @ Preshing on Programming - I/O in Plywood · 2 replies · +2 points

That's a good question. One possible answer is that it's simple this way. Another possible answer is that the converted data has to go somewhere, and Plywood's approach is to manage the destination buffer so that the caller doesn't have to. And while I didn't mention it in this post, there are functions to help you interpret the data in its "final form": For example, if you expect to read a binary message that's N bytes long, you can call InStream::tryMakeBytesAvailable(N) -- this will make sure that there are always N bytes available to read contiguously in memory starting at curByte, assuming EOF is not encountered.

To flip the question back around, how would you expect to eliminate one of the buffers? For example, what kind of data would you be reading? If you're reading a line of text, you don't know how long the line will be until after you've read it, so in general, there's no way to know what size of String to allocate ahead of time.

5 years ago @ Preshing on Programming - Memory Ordering at Com... · 0 replies · +4 points

Yes, if you make it a configuration option in your own project! Linux has its own configuration option for this: CONFIG_SMP. It's checked throughout the Linux source code to know whether it's compiling a kernel that will run on single processor system or multiple processor system.

5 years ago @ Preshing on Programming - Acquire and Release Fe... · 0 replies · +2 points

They compile to the same machine code on x86: https://godbolt.org/g/ZDW5wy

5 years ago @ Preshing on Programming - Acquire and Release Fe... · 0 replies · +2 points

I don't know. You could certainly devise an experiment to see if it makes any difference. But multicore x86 has been around for a long time, so I somehow doubt there are any wins to be found here.

5 years ago @ Preshing on Programming - Acquire and Release Se... · 0 replies · +4 points

Normally, the x86/64 doesn't reorder reads and doesn't reorder writes at the hardware level (among other things). That's why a compiler barrier is sufficient to implement those examples on x86/64. See Weak vs. Strong Memory Models.

5 years ago @ Preshing on Programming - The Synchronizes-With ... · 1 reply · +4 points

That's correct. TryReceiveMessage will eventually see ready=1. (In practice it happens in an extremely short time.)

IntenseDebate Comment System

Connect with Jeff Preshing

My blogs/sites

People I'm following

Jeff Preshing