Add 'pread'-backed method for thread-safe hunk reading

[xakep666]

Addressing proposal in #34

This PR adds method chd_read_threadsafe - a thread-safe version of chd_read. This method will be helpful for implementing threaded read-aheads purely by consumers without adding external dependencies (like pthread) .

My main programming language is Go and there's a popular approach "leave concurrency to a caller" used when concurrent code is written. And I think it fits good in this case.

Some implementation details:

• chd_read_threadsafe method has extra argument compressed_buffer which is used to store raw compressed data read from file. This is the one of two things required for thread-safety. chd_read uses same buffer stored in chd_file structure.
• Extra function pointer (interface method) fpread added to chd_core_file_callbacks to allow thread-safe reading from file. Used only in chd_read_threadsafe.
• On *nix libc's pread is being utilized for thread-safe reading from file
• On Windows ReadFile used for same purpose. Reference: https://github.com/aleitner/windows_pread
• On other platforms or in case fpread was not provided chd_read_threadsafe will return error CHDERR_NOT_SUPPORTED.
• hunk_read_into_memory has been tweaked a bit to accept arbitrary compressed data buffer pointer and different reading methods: seek_and_read (old one) or read_at (new one).

[rtissera]

@xakep666 Sorry this sat for months without a review.

The goal is right and I want it. "Leave concurrency to the caller" is the correct shape for this library, and driving it from Go without pthread is a constraint worth designing for — libchdr should not grow a threading dependency. Two things stop me merging it as it stands, and I would rather ask than decide alone.

The state sharing is wider than the two things this covers. Besides the compressed buffer and the file position, a read on current master also mutates the codec instances themselves (zlib and LZMA inflate state, cdfl's FLAC decoder and its buffer), the self-reference cache, the read-ahead window, and under LOWRAM_TARGET the map decode state and lazy codec init. Some of that landed after you opened this, which is also why it conflicts now. My concern is not that the PR is wrong, it is that two threads calling chd_read_threadsafe today would get silently wrong data rather than an error.

Did you hit this in ps3netsrv-go, or does your access pattern happen to avoid it? That would tell me how urgent the rest is.

Adding fpread to core_file_callbacks breaks the ABI. libchdr holds a caller-supplied pointer to that struct, so a consumer built against the older header passes one that is a pointer shorter, and the new code reads past its end. Same for the legacy core_file struct, which is the one PCSX2 fills in.

That part looks avoidable without giving anything up. Since the callbacks are reached through a pointer, the new entry point does not have to live in the struct:

typedef struct chd_core_file_pread_callbacks {
	size_t (*fpread)(void *buf, size_t len, uint64_t offset, void *argp);
} core_file_pread_callbacks;

CHD_EXPORT chd_error chd_set_pread_callbacks(chd_file *chd,
	const core_file_pread_callbacks *cb);

A new symbol, nothing existing grows, and your fallback stays as written: nothing registered, CHDERR_NOT_SUPPORTED. Would that work for you, or does your Go binding need it reachable from the callbacks struct itself?

Questions I do not have an answer to:

• Does your server need one handle shared across threads, or would several handles over a single file descriptor serve you equally well? The second is much easier to make correct, and pread is what makes it cheap.
• Have you measured what pread saves over seek-then-read in your workload? If it is significant on its own, it is worth landing separately from any threading question.
• The Windows path uses OVERLAPPED on a synchronous handle, which still advances the file pointer, so it is not position-neutral against a concurrent chd_read on the same handle. Was that deliberate, or worth revisiting?

The fpread idea is the part I am most interested in keeping, and it stands on its own. I am less sure about chd_read_threadsafe under that name while it is not one — but tell me what you actually need and I will work from that.