Friday Night Dinner: Kin

Almost next to BBC Broadcasting House, Kin is a plant based restaurant. During the day it's a café with vegan snacks. In the evening it transforms into a modern restaurant with plant based dishes.

On a warm evening, we decided to sit inside in a fairly cool and quiet space. There were a few other diners enjoying the fine weather, eating outside. We usually avoid sitting outside as smoking and vaping tends to spoil the experience.

To start our meal, we shared the Sticky Cashew Tofu, and the Mushroom Skewers (on toast). The tofu was flavourful, and crispy, and the carrot dip added a bit more creaminess — this was my wife's favourite starter. The Mushroom Skewers were made up of oyster mushrooms, which were a little chewy to create some texture, and were served with an artichoke dip spread. Heaps of spring onion and chilli were tossed on top.

For her main, my wife chose the Cauliflower and Butter Bean Curry — Thai flavours and with roasted cashew nuts for texture, which she very much enjoyed. I had the Miso-Glazed Aubergine, which was served with cauliflower purée. The flavours were great, and the aubergine worked well with the cauliflower, but I found it mono-textural, lacking something crunchy as a contrasting texture. I also thought it was too much portion wise, but that was perhaps because we also already had starters too, or maybe we have smaller appetites. We were really full, so pudding didn't appeal, and we left to walk the fairly short distance to the tube.

When we left, it was a lot busier inside, and also a lot louder — perhaps a little too loud for our general liking.

All-in-all, we enjoyed a flavourful meal, and although most of the dishes had some texture, I found the aubergine dish lacking. But it's a good place for plant-based cuisine.

Oyster Mushroom Skewers
Oyster Mushroom Skewers
1 / 4
Sticky Cashew Tofu
Sticky Cashew Tofu
2 / 4
Miso-Glazed Aubergine
Miso-Glazed Aubergine
3 / 4
Cauliflower and Butter Bean Curry
Cauliflower and Butter Bean Curry
4 / 4

Shortlink

This article has a short URL available: https://drck.me/kin-kbt

Likes

Comments

@fridaynightdinners It's weird travelling and experiencing the different ways places handle smoking and vaping.

I think Ontario banned smoking on patios a decade ago. I just got back from B.C. where it's still allowed.

Every time I go to Spain I get the feeling they're still in the era of "The Surgeon General Smokes Camels".

Friday Night Dinner: Poon's at Somerset House

Poon's is a stone throw away from the bustling Lancaster Place, in the New Wing of Somerset House. The room is bright, and has normal tables, a few high tables, and a communal style arrangement. We were seated at one of the high tables in the corner near the entrance, facing out with a good view over the interior.

At first glance the menu looks deceptively simple, but on closer examination there were many delicious options to choose from

We started with some pan-fried wind-dried sausage, which was slightly sticky, salty and delicious. We also shared a portion of The Hill That Amy Didn't Die On, a long-winded name for a prawn toast. But well done, and more like croquettes than the traditional flat shape — we're not sure that it actually involved bread.

For our mains I ordered the Char Siu, beautifully roasted pork belly with a sticky glaze. Some steamed rice was great for soaking up the juices. My wife chose the Steamed Catch of the Day. Today's was a Brill, which was presented whole, but taken off the bone for us. It was served with mushrooms — some of which were cut into strips and tied into little knots — and some greens. We shared more of these dishes than we would normally do.

We did not have space for desert as well, and instead enjoyed a digestive.

The meal was great, but it did end up being a little pricier than originally expected. But our digestive had something to do with that.

Poon's had a wonderful atmosphere, delicious food and welcoming staff, we'd definitely return and would recommend.

The Hill that Amy Didn't Die On
The Hill that Amy Didn't Die On
1 / 4
Wind-Dried Sausages
Wind-Dried Sausages
2 / 4
Char Siu
Char Siu
3 / 4
Steamed Brill
Steamed Brill
4 / 4

Shortlink

This article has a short URL available: https://drck.me/poons-kbj

Likes

Comments

No comments yet

Fail Faster

For a long time I have heard complaints that Xdebug, with its debugger enabled, slows down applications, even if there is no IDE listening.

I have never been able to reproduce this, as on Linux (and macOS), TCP connections to a localhost ports fail immediately if that port is not open.

Xdebug waits for up to 200ms when making a debug connection. This is configurable with the xdebug.connect_timeout_ms setting.

But if there is nothing listening, there should not be any delay, as it ought to be an immediate error.

I wrote a comment in an issue from 2024:

The error message ERR: Time-out connecting to debugging client, waited: 200 ms. indicates that your network stack doesn't immediately reject the connection if it can't be made. That's usually due to a (misconfigured) firewall.

It turns out, that it is not a firewall, but that Windows itself behaves bad here. Instead of failing immediately, it does retry sending TCP SYN packets to try to establish a connection. This is pointless on the local loopback interface, as network packets cannot get lost.

Through a post by Daniel Stenberg on Mastodon, I found out the cause, and a solution.

He explains how it affects curl's Happy Eyeballs algorithm in a blog post from 2024. Although Xdebug does not use Happy Eyeballs, the underlying problem is the same.

Last week, Marcel Jamin wrote to the curl mailing list, with a solution. This solution disables the retry mechanism to establish a connection. And in turn that means, that there is no longer a delay on Windows either.

I have today merged a pull request for Xdebug which implements this solution. The patch is part of the upcoming Xdebug 3.6 release.

Shortlink

This article has a short URL available: https://drck.me/fail-faster-kbh

Comments

@blog nice one

@blog I think it probably is a firewall issue really, unless Windows is ignoring the RST packets that tell it nothing is listening.

That's what happens on linux - the SYN is sent and gets an RST and that is reported as a connection failure with EPORTUNREACH but if you firewall loopback so it doesn't get the RST then you get the Windows behaviour of it retrying SYN packets.

There's nothing special about the loopback handling in linux.

Become a Patron!
Mastodon
GitHub
LinkedIn
RSS Feed
Flickr
YouTube
Vimeo
Email

My Amazon wishlist can be found here.

Human-Made Webring
previous | random | next

Life Line