From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master 8dcb19f 4/4: Add a unit test testing interaction between threads and processes. Date: Sun, 24 Jan 2021 17:30:15 +0200 Message-ID: <838s8i4ak8.fsf@gnu.org> References: <83k0s34eo1.fsf@gnu.org> <83h7n74cwe.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18599"; mail-complaints-to="usenet@ciao.gmane.io" Cc: phst@google.com, emacs-devel@gnu.org To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 24 16:30:50 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l3hLl-0004kd-NU for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Jan 2021 16:30:49 +0100 Original-Received: from localhost ([::1]:33170 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l3hLk-0001X6-Nq for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Jan 2021 10:30:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53362) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l3hLC-00015J-45 for emacs-devel@gnu.org; Sun, 24 Jan 2021 10:30:14 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59959) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l3hLB-0000ui-Qb; Sun, 24 Jan 2021 10:30:13 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2143 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l3hLA-0003Zk-N3; Sun, 24 Jan 2021 10:30:13 -0500 In-Reply-To: (message from Philipp Stephani on Sun, 24 Jan 2021 14:22:57 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:263342 Archived-At: > From: Philipp Stephani > Date: Sun, 24 Jan 2021 14:22:57 +0100 > Cc: Philipp Stephani , Emacs developers > Right now we don't have that many good tests that test the interaction > between threads and processes, so the intention of this test is to > improve coverage in this area. The general intent is clear and welcome; it's the details that I'm interested in, because I need to know which, if any, parts of the Windows emulation of the sub-process support need to be improved or fixed. > > There are some things the code does whose rationale I > > don't understand. For example, why the call to set-process-thread: > > what's the purpose? > > The test wouldn't work without it, because it calls > accept-process-output from a thread different from the thread in which > the process was created. But set-process-thread accepts a thread argument, so you could bind the process to a particular thread, couldn't you? More generally, my reading of the code is that the first thread which calls accept-process-output will start listening on all the file descriptors of all the sub-processes which were started until then, and all the other threads will have no descriptors left to listen on. Is this the situation you intended to create? And if so, is this an interesting practical use case, or are we just testing implementation details? > > Or why no-conversion in make-process? > > Unit tests should typically test only one aspect, or a small number of > related aspects of the system under test. The goal of this test is not > to test the encoding procedures, so I turn off encoding here. Thanks, so I now understand that the encoding stuff is not important (since the subprocess doesn't produce any output, it cannot have any effect, AFAIU). > > More > > generally, what is the basic idea of the test and the expectation > > from each thread. > > I don't understand this question. The idea is to have a test that > calls accept-process-output from multiple threads to increase coverage > in this area. Why is it important to test this situation, and what do we expect to happen in it? Is it reasonable to have more than one thread wait for output from a subprocess? > > > thread-join should yield. > > > > Isn't that too late? The processes have exited already, so what does > > that test? > > Again, I don't understand this question. Each unit test is a runnable > example: by writing it, we document some aspect about how Emacs Lisp > should behave, and by running it, we can find bugs (mismatches between > the intended and the actual behavior) and regressions. The question I ask myself is what to do with the deviant behavior on MS-Windows. If it behaves differently because what we test here are the peculiarities of the semi-broken Unix mechanism known as "signals" and/or some details of our implementation of subprocesses on Posix platforms, then maybe there's no need to change anything in the Windows code, and just either skip this test on MS-Windows or write a different test which will work there. IOW, in such a case there's no bug in the Windows port, it's just that it isn't bug-for-bug compatible with Unix. But if what happens in this test is important in practical use cases, then perhaps our Windows code does need some changes in this area. This is why I'm trying to understand the semantics of this test -- I'd like to figure out which implementation details are important, and thus should be emulated on Windows, and which are just details that can be different (and portable Lisp programs will have to take those differences into account). For example, the test verifies that each process exited with zero status, but it doesn't care which thread detected that -- is this important? Or what about delivery of SIGCHLD -- is this important which thread gets delivered the signal, or how many threads should the signal wake up? Or is it important when and due to what reason(s) does each thread exit? Can you please help me understand these and other related issues?