From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21804 invoked by alias); 11 Feb 2017 19:46:23 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 40528 Received: (qmail 2968 invoked from network); 11 Feb 2017 19:46:23 -0000 X-Qmail-Scanner-Diagnostics: from mail-vk0-f68.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.213.68):SA:0(-0.0/5.0):. Processed in 1.821121 secs); 11 Feb 2017 19:46:23 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.213.68 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=G+c6HlsWI094cnRepHSS51KcFhbKMV+mYtdGQd2ePp8=; b=dhQdnKPlbYKqpLaiIYsPFvIt2ULhwZoJ8arJHEbfWfAR1wc/7n3jxcngVqv3kfdNFo 2FgjXlQ0DZ/HI90Y0CwZyRK/eVbm5aDa4tabBArm9juy8QfqCE2v4mLLF4B5/3/4qxs+ J3NX2MBVDB7OGUwYbsUgQtom0F7PH9NCwER/OIyruvbG5POx0w7c+AIZ4lUc+Km6rouV xYy3fzRd57ok1dPsV4/OsRCXflS5tmCZeiT2O71UCIe95QGIzwUz9ffrdMkYTcwQ8VQZ MquHloNtLhEP9PbdvfaD5ZXeNhO/I31o7g4ARVpTEBdkU2ZdCiEcqDjOORiy4ev4IShv +DxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=G+c6HlsWI094cnRepHSS51KcFhbKMV+mYtdGQd2ePp8=; b=qJFJWFJpzue3CMjOklcwQFq+JMUQK/XbHThhXHyCYUXmISYroU9Qc69cAJ4LfMdBtM NmMqPgIeGwrjzaJQXDHZhD5Zv5FjtghWJZkWJIYKftNMqzqSbKQGRQ63GiX0Ifui8glP rH/fnTHVZWJZwMcJmaMl/zkrCDZutxWHLny4NVDjthFc+PuV7xpOO5BPHIjtd048kB5s nS+7gkUdprStRMZQGyC9ubg/RGR9SSpc1ENMVVhCyXIatrm51w+DpqCYjrNsYfbEorWz ibxGg5IFDnT+IYLzzweYTYWpTOS6UkMrPXxTJ+hHmB6OvHtCC56H7Cj0pNxaQM1Ik/qC p5HQ== X-Gm-Message-State: AMke39l/fFSLlvqRtF54D0uMBVIMWFnL1y86AROtxE5UYgYRBnj3jFNp5eTdUXLRI3dFKg== X-Received: by 10.31.134.142 with SMTP id i136mr7788425vkd.56.1486842375192; Sat, 11 Feb 2017 11:46:15 -0800 (PST) From: Bart Schaefer Message-Id: <170211114632.ZM665@torch.brasslantern.com> Date: Sat, 11 Feb 2017 11:46:32 -0800 In-Reply-To: <1486817916.2745591.877718432.2CE18595@webmail.messagingengine.com> Comments: In reply to Sebastian Gniazdowski "Multithreading support in pluggable module, but with problems" (Feb 11, 4:58am) References: <1486817916.2745591.877718432.2CE18595@webmail.messagingengine.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Multithreading support in pluggable module, but with problems MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 11, 4:58am, Sebastian Gniazdowski wrote: } Subject: Multithreading support in pluggable module, but with problems } } # zpin 'print -rl "a:b" "c:d"' | zpopulator -A my_hash } } This is done entirely in background. zpin does fork() and this way makes } Zsh think it's finished - main process exits. zpopulator starts a thread } and makes main thread exit - this is also sufficient to make Zsh think } that there is no background job. So if I understand this correctly, you're attempting to use POSIX threads to share the my_hash variable between the main shell and a 2nd thread of which the main shell is not aware, so that the 2nd thread can stuff a value into my_hash while the main thread goes on about its business? I can almost promise you there is no way to make that work, at least not in a crash-proof manner. Even making my_hash PM_READONLY -- which is I presume what yesterday's question was about -- what is there to stop the thread-unaware main shell from accessing it at a time when the 2nd thread is changing it in some way that will send the main thread off into uncharted memory? Aside from that, you're running directly afoul of the presecribed behavior of file descriptor management for shells, which amounts to a prohibition on passing unexpected file descriptors down to any forked children. If you want to keep a descriptor around, you have to manipulate it with the routines in Src/utils.c that manage the fdtable array. In particular you *might* need to call either movefd() or redup() rather than call dup2() directly, and you should otherwise be using addmodulefd() to protect the fd from exec.c:closeallelse(). Examples in Src/Modules/tcp.c.