flak rss random

sometimes syscalls restart

Yesterday Reyk fixed a tiny bug in vmd. It wasn’t possible to kill the process by pressing ^C. As explained in the commit, the accept4 system call was being restarted after the signal.

By default, most signal handlers that a program establishes have the SA_RESTART flag set, which causes an interrupted system call to be restarted. Actually, by default signals are either ignored or cause the program to terminate, so this isn’t a problem at all, but any handler installed by calling signal sets this flag. More control over signal actions is possible using the appropriately named sigaction function.

On the kernel side, system calls that need to block call tsleep which usually waits for a corresponding wakeup or a timeout to expire. However, it may also return an error (ERESTART) if it’s interrupted by a signal. Most system calls don’t inspect the error code, they simply pass it along. But when the kernel is about to return to userland, it will notice this error code and run the syscall again.

Among the system calls that handle ERESTART specially are poll, select, and kevent. All of them check for ERESTART and immediately map it to EINTR so it gets returned to userland.

Back in vmd, it had installed a SIGTERM handler that set a quit flag variable to true, but was getting stuck in accept. The code looking at quit never had a chance to run. The fix was to add a call to poll before accept.

Most of the time the default behaviors make sense. Restarting system calls prevents a lot of spurious failures from propagating. Applications that install signal handlers usually use one of the interruptible functions in the core of their event loop. vmd happened to be an exception, that only needed to handle one event and tried to take a shortcut.

Additional commentary about history of EINTR.

Posted 24 Nov 2015 17:52 by tedu Updated: 20 Jun 2019 01:08
Tagged: c openbsd programming

going full pledge

Looking at Theo’s status of pledge update there’s a lot of programs on the list, including some which may seem a bit silly. But the effort has turned up some interesting bugs and misfeatures along the way.

more...

Posted 20 Nov 2015 18:33 by tedu Updated: 20 Nov 2015 18:33
Tagged: openbsd software

utf-achtung

Previous post on rough code had some notes notes on a few of the issues we faced at ü2k15. I also collected some notes and links about utf-8 and unicode that weren’t directly OpenBSD related.

more...

Posted 19 Nov 2015 06:30 by tedu Updated: 11 May 2016 00:30
Tagged: software

counting up vs counting down

The “traditional” way of writing a for loop looks something like this:

more...

Posted 18 Nov 2015 15:56 by tedu Updated: 19 Nov 2015 16:31
Tagged: c programming

rough code and working consensus

On their better days, standards groups follow a principle of rough consensus and working code. Somebody builds something, announces it to some friends and maybe a few competitors, and says, hey, if you build something similar, it’s possible for our implementations to interoperate. Everyone’s a winner. Sometimes the design isn’t perfect, but the fact that at least one person/group has built an implementation is an existence proof that it can be built. Valuable knowledge to have.

more...

Posted 17 Nov 2015 14:48 by tedu Updated: 19 Nov 2015 06:31
Tagged: openbsd programming thoughts

sct - set color temperature

The recent fuss about f.lux on iPhone made me take another look at desktop solutions for shifting the screen’s color temperature. f.lux is only available as a linux binary, but there’s a program called redshift that may work.

more...

Posted 16 Nov 2015 16:34 by tedu Updated: 13 Dec 2018 21:09
Tagged: openbsd programming project software x11

starting from scratch bugs

Or everything I didn’t know about unix. The OpenBSD source tree has lots of example code for solving any number of problems, but I like to do things my own way. Occasionally this means something gets overlooked. A few examples. Previous thoughts on rewrites and reuse: out with the old, in with the less and hoarding and reuse.

more...

Posted 04 Nov 2015 06:11 by tedu Updated: 04 Nov 2015 06:11
Tagged: c openbsd programming

pinboard tips for web design

A few funnies sprinkled with a bit of insight and disappointment. And regret.

It’s 2015. Your team has to wake up determined and put in one hell of a work week to get web pages to render slowly. And yet so many succeed. tweet.

My modest proposal: your website should not exceed in file size the major works of Russian literature. Anna Karenina, for example, is 1.8 MB. tweet.

If your design team insists on including a lot of Javascript cruft and CSS resets, make them write it all out longhand with a quill pen. tweet.

Two steps to better mobile design: 1) Make sure that the most critical elements of the page download and render first. 2) Stop right there. tweet.

If you’re a web designer/front-end developer, It may help to think of the fan on your laptop as a shaming rather than a cooling device. tweet.

The only honest measure of page load speed: time from initial TLS handshake to when the user has finally stopped closing all the ads. tweet.

More generally, there should be an attribute to allow non-designers’ browsers to only load useful images. tweet.

Astonished to find that a blog site needs a Bloom filter daemon and has Product Scientists. “On the web we want to stay close to the metal” tweet.

I move that the web get faster as computers and networks get faster. tweet.

“We aspire to simple, powerful, yet revenue-free systems that can turn a 500 word blog post into a multi-megabyte user experience” tweet.

All this and more also collected in The Website Obesity Crisis talk.

Posted 04 Nov 2015 06:10 by tedu Updated: 01 Jan 2016 14:04
Tagged: quote rants web

iphone 6s plus

Replaced my 5s with the new top of the line, 6s plus. Kind of an awkward name. I propose 7P and 7Ps for the next gen.

more...

Posted 30 Oct 2015 01:44 by tedu Updated: 30 Oct 2015 01:44
Tagged: gadget review

bring your own customer service

Skip the middleman to save time and money by simply telling your customers exactly what you would have told your customer service team. Simple direct communications mean nothing gets lost in translation. Not even funtioning.

cust serv

Best of all, if they screw up, it’s their own fault.

Posted 23 Oct 2015 17:42 by tedu Updated: 23 Oct 2015 17:44
Tagged: bugs web