Re: [quicwg/base-drafts] create codec streams only when necessary (#2090)

Kazuho Oku <notifications@github.com> Thu, 13 December 2018 03:36 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A639128CFD for <quic-issues@ietfa.amsl.com>; Wed, 12 Dec 2018 19:36:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fq080CNSa75J for <quic-issues@ietfa.amsl.com>; Wed, 12 Dec 2018 19:36:01 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80AD5124D68 for <quic-issues@ietf.org>; Wed, 12 Dec 2018 19:36:01 -0800 (PST)
Date: Wed, 12 Dec 2018 19:35:59 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1544672159; bh=wVngkbEKaWMAvGxpQYly/QQF4gTAC0tkXe/VrQJRJkg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=R3/p5FN4NDDBxGJ3n1Q/CHYGdwgxUqPb56GhXHuh77xNu3dn5QBYhHU8i2VX+kGI1 tdbRnN6FUIs0mTwGKUMXEtYmDbhCRbM7OaSdxrEYfCYQffDjoi9D8zB56rWcfJVuAM lAdYSK4TKEzRQCu6wskq0GWGCMFES57QMyXD/6C8=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab2682452c0c4799fea8c168f900f91f3ba1aa1da992cf000000011829959f92a169ce170ba08e@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2090/c446831416@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2090@github.com>
References: <quicwg/base-drafts/pull/2090@github.com>
Subject: Re: [quicwg/base-drafts] create codec streams only when necessary (#2090)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c11d39fdd56a_515e3fe4a36d45bc189334"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/C4TeikDv2lvhPX2tzhqddySH4dY>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2018 03:36:04 -0000

@martinthomson 
> Let me try to expand on my earlier comment. I currently create these streams when building my connection object. This allows requests and responses to use those streams directly. If the streams might not exist, then I have to allow those values to be absent throughout, which is annoying but not a big deal. More of a concern is that this is concurrent code, so deferring creation would mean that I would have to guard the variables holding the streams with a mutex (or atomic, which always gives me the creeps). That creates the potential for contention point on every new message.

Isn't it the case that you would be having contention point even without the proposed change, assuming that you are creating the connection object prior to receiving the SETTINGS frame? I ask this because the receipt of SETTINGS_MAX_TABLE_SIZE updates the state of the QPACK encoder.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2090#issuecomment-446831416