From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) by sourceware.org (Postfix) with ESMTPS id CB3C33886C4F for ; Tue, 8 Jun 2021 22:11:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CB3C33886C4F Received: by mail-lj1-x22e.google.com with SMTP id x14so14724038ljp.7 for ; Tue, 08 Jun 2021 15:11:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MbDNBRH1OFAdrrOwiRyRqVDbr3B/JafM4/SqsbQ7IIU=; b=huhwhi/vogc8CNdMI/VKDLXPhpETYuxi9w+w+Fx9ZE4cpAApkt0+UDddUwldhHT9+q nBSDCK+hLoXglYdWM6ObVTNtiVi+u6F7cI95AsUEvzx7hJc19XBr18dMQQ/I79lq5VUH +4WnIXwrmuCwQ1lazNsziOyXMz+3ubwXsU7PFd4a0cDFQ1iM/jFifnFq6GXmnrlJx2ah R6rCUkJ0QiezcEF4KTMiNyYUGFUEks3dqkQZ4tfpkzn3DSPl0L0v1UjhEmXGyL5doQcz 86lCTL5TDfFt0nHyJt20G+y8eGkpa4VLk+W5n1w+AE2f0hUwtmkQWOs/jh7TcBYVw9PR zamQ== X-Gm-Message-State: AOAM533MpcAnsbCY9sK1+CsKbfeH0PsbHN4BSzdjKkMkEmZL80wBJ4Wv as/mkinxYxPCmUeJoLmsOG7MHW3JhgKWsNpUFQ8= X-Google-Smtp-Source: ABdhPJz6flsH5gEAJO/5dTrZP9Mw9ZFc3oULt0ziYsPfw0QEkCI9XbkADzcvUML7FsNvwrH3vn11Q3blbimgcMk7v7o= X-Received: by 2002:a2e:988e:: with SMTP id b14mr19808802ljj.328.1623190305567; Tue, 08 Jun 2021 15:11:45 -0700 (PDT) MIME-Version: 1.0 References: <7298cb72-becb-80bb-b2df-d97bdb201e95@linaro.org> <11145e53-3fbc-0f04-33f8-b2d9981f0ea8@linaro.org> In-Reply-To: <11145e53-3fbc-0f04-33f8-b2d9981f0ea8@linaro.org> From: Godmar Back Date: Tue, 8 Jun 2021 18:11:33 -0400 Message-ID: Subject: Re: supporting terminal ownership assignment (tcsetpgrp()) in posix_spawn To: Adhemerval Zanella Cc: Libc-help X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 22:11:48 -0000 On Tue, Jun 8, 2021 at 12:42 PM Adhemerval Zanella < adhemerval.zanella@linaro.org> wrote: > > > > > >> > >> If the caller already has group it want to use, it can issue instead: > >> > >> posix_spawnattr_t attr; > >> posix_spawnattr_setpgroup (&attr, groupid); > >> posix_spawnattr_tcsetpgrp_np (&attr, fd, groupid); > >> > >> Which in turn will make the created process to issue: > >> > >> setpgid (0, groupid); > >> tcsetpgrp (fd, groupid); > >> > > > > For this use case, as long as it supports groupid == 0, this should work > as > > it is what shells currently do. > > So the my question is whether providing the groupid as an argument is > really required (I would say yes so it can be combined with > posix_spawnattr_setpgroup). > The Blackberry API does not pass an argument (as a point of reference). In practice, when spawning a pipeline like a | b | c ... we pass group id 0 to the first child, and then the pid if of the first child as the pgrp id to the second and third. This means that if the groupid is omitted, it needs to refer to the group id that was given to POSIX_SPAWN_SETPGROUP, and thus POSIX_SPAWN_SETPGROUP is a prerequisite for it. > > Another question is when to issue the tcsetpgrp related to > POSIX_SPAWN_SETSID. I would say tcsetpgrp should be issued *before* > setsid, so tcsetpgrp can return early if it fails. Otherwise tcsetpgrp > will always fail if POSIX_SPAWN_SETSID is set (it would be a caller > error, but I think from API viewpoint it should be better if we could > minimize the possible error scenarios). > I haven't checked how the current implementation works. Do you use a pipe or something for the child to report back if something went wrong, or does the parent somehow check if the asked-for actions in the child will likely succeed? If the former, doing setsid first, and then, if given, doing the tcsetpgrp call will fail as you say and this failure would be reported back to the caller. Then they know they've misused the API. If you do tcsetpgrp first and then setsid, the tcsetpgrp will succeed, but will be ineffective, and the caller won't ever know.