Zpdf: PDF text extraction in Zig • Hacker News Board

Re: Zpdf: PDF text extraction in Zig

#81

Post by jibal » Wed, Dec 31, 2025, 8:53 PM UTC

StilesCrisis wrote: post #49

rishabhaiover wrote: post #41

Earlier quoted context omitted.

I don't fully understand the under the hood mechanics of mmap, but I can sense that you're trying to convey that mmap shouldn't be used a blanket optimization technique as there are tradeoffs in terms of page fault overheads (being at the mercy of OS page cache mechanics)

Tradeoffs such as "if an I/O error occurs, the program immediately segfaults." Also, I doubt you're I/O bound to the point where mmap noticeably better than read, but I guess it's fine for an experiment.

An I/O error on a mmapped file causes a SIGBUS, which the program can catch and report.

And I/O bound programs are I/O bound whereas programs that aren't, aren't, so it really isn't meaningful to talk about whether "you" are I/O bound to the point that it's significant--maybe you are, maybe you aren't. I agree about experimentation.

Re: Zpdf: PDF text extraction in Zig

#82

Post by SQLite » Thu, Jan 01, 2026, 12:05 AM UTC

nextaccountic wrote: post #79

kennethallen wrote: post #52

Earlier quoted context omitted.

Two big advantages: You avoid an unnecessary copy. Normal read system call gets the data from disk hardware into the kernel page cache and then copies it into the buffer you provide in your process memory. With mmap, the page cache is mapped directly into your process memory, no copy. All running processes share the mapped copy of the file. There are a lot of downsides to mmap: you lose explicit error handling and fi…

> Consult the classic article on why sophisticated systems like DBMSs do not use mmap: https://db.cs.cmu.edu/mmap-cidr2022/ Sqlite does (or can optionally use mmap). How come? Is sqlite with mmap less reliable or anything?

If an I/O error happens with read()/write(), you get back an error code, which SQLite can deal with and pass back up to the application, perhaps accompanied by a reasonable error message. But if you get an I/O error with mmap, you get a signal. SQLite itself ought not be setting signal handlers, as that is the domain of the application and SQLite is just a lowly library. And even if SQLite could set signal handlers, it would be difficult to associate a signal with a particular I/O operation. So there isn't a good way to deal with I/O errors when using mmap(). With mmap(), you just have to assume that the filesystem/mass-storage works flawlessly and never runs out of space.

SQLite can use mmap(). That is a tested and supported capability. But we don't advocate it because of the inability to precisely identify I/O errors and report them back up into the application.

Re: Zpdf: PDF text extraction in Zig

#83

Post by grayhatter » Thu, Jan 01, 2026, 9:27 AM UTC

lulzx wrote: post #75

littlestymaar wrote: post #74

Earlier quoted context omitted.

> I have updated the licence to WTFPL. You still have no basis in claiming copyright protection hence you cannot set a license on that code. Instead of the WTFPL you should just write a disclaimer that due to being machine generated and devoid of creating work, the work is not protected by copyright and free to be used without any license.

hasn't world moved on from these things already?

Has the world moved on from copyright? Or expecting other people to behave ethically and fairly?

No, and god I hope not.

But it's a real dick move to set up your CI the way you have. Zig explicitly requests using one of the many mirrors for CI instead of hammering the main ziglang.org site itself. Perhaps you've moved on from trying to be ethical?

Re: Zpdf: PDF text extraction in Zig

#84

Post by lulzx » Thu, Jan 01, 2026, 9:56 AM UTC

grayhatter wrote: post #83

lulzx wrote: post #75

Earlier quoted context omitted.

hasn't world moved on from these things already?

Has the world moved on from copyright? Or expecting other people to behave ethically and fairly? No, and god I hope not. But it's a real dick move to set up your CI the way you have. Zig explicitly requests using one of the many mirrors for CI instead of hammering the main ziglang.org site itself. Perhaps you've moved on from trying to be ethical?

That's good to know, I wasn't aware of it, I have updated to using a github action they recommend (https://github.com/marketplace/actions/setup-zig-compiler)

For the copyright thing, I understand that there's legit ongoing debate around all this AI-assisted coding and copyrightability.

In this case of zpdf, while Claude Code did a lot of the heavy lifting on implementation, there was a real effort in architecture decisions, iterative prompting/refinement, debugging, testing, benchmarking.

My intent is zero restrictions: use it, fork it, sell it, whatever. WTFPL captures that spirit perfectly for me. It's as permissive as legally possible while being upfront about not caring.

The goal is just to make a useful tool freely available.

Edit: I have changed it to CC0.

Re: Zpdf: PDF text extraction in Zig

#85

Post by nextaccountic » Thu, Jan 01, 2026, 5:37 PM UTC

jeffbee wrote: post #80

nextaccountic wrote: post #79

Earlier quoted context omitted.

> Consult the classic article on why sophisticated systems like DBMSs do not use mmap: https://db.cs.cmu.edu/mmap-cidr2022/ Sqlite does (or can optionally use mmap). How come? Is sqlite with mmap less reliable or anything?

I know that the spirit of HN will strike me down for this, but sqlite is not a "sophisticated system". It assumes the hardware is lawful neutral. Real hardware is chaotic. Sqlite has a good reputation because it is very easy to use. In fact this is the same reason programmers like mmap: it is a hell of a shortcut.

I think the main thing is whether mmap will make sqlite lose data or otherwise corrupt already committed data

... it will if two programs open the same sqlite, one with mmap, and another without https://www.sqlite.org/mmap.html - at least "in some operating systems" (no mention of which ones)

https://www.sqlite.org/mmap.html

> The operating system must have a unified buffer cache in order for the memory-mapped I/O extension to work correctly, especially in situations where two processes are accessing the same database file and one process is using memory-mapped I/O while the other is not. Not all operating systems have a unified buffer cache. In some operating systems that claim to have a unified buffer cache, the implementation is buggy and can lead to corrupt databases.

Sqlite is otherwise rock solid and won't lose data as easily

Re: Zpdf: PDF text extraction in Zig

#86

Post by nextaccountic » Thu, Jan 01, 2026, 6:07 PM UTC

SQLite wrote: post #82

nextaccountic wrote: post #79

Earlier quoted context omitted.

> Consult the classic article on why sophisticated systems like DBMSs do not use mmap: https://db.cs.cmu.edu/mmap-cidr2022/ Sqlite does (or can optionally use mmap). How come? Is sqlite with mmap less reliable or anything?

If an I/O error happens with read()/write(), you get back an error code, which SQLite can deal with and pass back up to the application, perhaps accompanied by a reasonable error message. But if you get an I/O error with mmap, you get a signal. SQLite itself ought not be setting signal handlers, as that is the domain of the application and SQLite is just a lowly library. And even if SQLite could set signal handlers,…

Thanks for the response. I am more worried about losing already committed data due to an error

https://www.sqlite.org/mmap.html

> The operating system must have a unified buffer cache in order for the memory-mapped I/O extension to work correctly, especially in situations where two processes are accessing the same database file and one process is using memory-mapped I/O while the other is not. Not all operating systems have a unified buffer cache. In some operating systems that claim to have a unified buffer cache, the implementation is buggy and can lead to corrupt databases.

What are those OSes with buggy unified buffer caches? More importantly, is there a list of platforms where the use of mmap in sqlite can lead to data loss?

Re: Zpdf: PDF text extraction in Zig

#87

Post by kennethallen » Fri, Jan 02, 2026, 12:34 AM UTC

commandersaki wrote: post #68

kennethallen wrote: post #52

Earlier quoted context omitted.

Two big advantages: You avoid an unnecessary copy. Normal read system call gets the data from disk hardware into the kernel page cache and then copies it into the buffer you provide in your process memory. With mmap, the page cache is mapped directly into your process memory, no copy. All running processes share the mapped copy of the file. There are a lot of downsides to mmap: you lose explicit error handling and fi…

you lose explicit error handling I've never had to use mmap but this is always been the issue in my head. If you're treating I/O as memory pages, what happens when you read a page and it needs to "fault" by reading the backing storage but the storage fails to deliver? What can be said at that point, or does the program crash?

If you fail to load an mmapped page because of an I/O error, Unix-like OSes interrupt your program with SIGBUS/SIGSEGV. It might be technically possible to write a program that would handle those signals and recover, but it seems like a lot more work and complexity than just checking errno after a read system call.

Re: Zpdf: PDF text extraction in Zig

#88

Post by kennethallen » Fri, Jan 02, 2026, 12:54 AM UTC

saidinesh5 wrote: post #55

kennethallen wrote: post #52

Earlier quoted context omitted.

Two big advantages: You avoid an unnecessary copy. Normal read system call gets the data from disk hardware into the kernel page cache and then copies it into the buffer you provide in your process memory. With mmap, the page cache is mapped directly into your process memory, no copy. All running processes share the mapped copy of the file. There are a lot of downsides to mmap: you lose explicit error handling and fi…

This is a very interesting link. I didn't expect mmap to be less performant than read() calls. I now wonder which use cases would mmap suit better - if any... > All running processes share the mapped copy of the file. So something like building linkers that deal with read only shared libraries "plugins" etc ..?

mmap is better when:

  * You want your program to crash on any I/O error because you wouldn't handle them anyway
  * You value the programming convenience of being able to treat a file on disk as if the entire thing exists in memory
  * The performance is good enough for your use. As the article showed, sequential scan performance is as good as direct I/O until the page cache fills up *from a single SSD*, and random access performance is as good as direct I/O until the page cache fills up *if you use MADV_RANDOM*. If your data doesn't fit in memory, or is across multiple storage devices, or you don't correctly advise the OS about your access patterns, mmap will probably be much slower

To be clear, normal I/O still benefits from the OS's shared page cache, where files that other processes have loaded will probably still be in memory, avoiding waiting on the storage device. But each normal I/O process incurs the space and time cost of a copy into its private memory, unlike mmap.