From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28166 invoked from network); 10 Nov 2023 02:24:16 -0000 Received: from tb-ob1.topicbox.com (64.147.108.173) by inbox.vuxu.org with ESMTPUTF8; 10 Nov 2023 02:24:16 -0000 Received: from tb-mx1.topicbox.com (tb-mx1.nyi.icgroup.com [10.90.30.61]) by tb-ob1.topicbox.com (Postfix) with ESMTP id 09E4E2DF17 for ; Thu, 9 Nov 2023 21:24:14 -0500 (EST) (envelope-from bounce.mMfe4be6cb472537ea35f1d195.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx1.topicbox.com (Postfix, from userid 1132) id 0639A32A1A4; Thu, 9 Nov 2023 21:24:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=to:subject :message-id:references:in-reply-to:date:mime-version :content-type:content-transfer-encoding:list-help:list-id :list-post:list-subscribe:reply-to:from:list-unsubscribe; s= dkim-1; t=1699583053; x=1699669453; bh=fi+OP6jJhvXYAWJkNSQAXLt79 Lf9SMBLa3cgF5kJBGg=; b=oxrqJImbIFnI5jFRQ/sdIWmu/r2/t2MroPHTzEQik azuST0aYFu2e3xTeQdvv7QlUsPp/VbKvhy29xvStXdHVLzKwIaxYtzxC7roJ/obc /UE5qtLkZ7E/pp85hpzCcYm4jNfdFQE4JGZvKC5c8TDnfpIfGSfIJ3KAaBXtk1Vr nk= To: 9fans <9fans@9fans.net> Subject: Re: [9fans] odd rwakeup qunlock behaviour in 9vx Message-Id: <16995830470.DAEce1.126202@composer.9fans.topicbox.com> References: <05DC7BC5698D779E601D2AB8E1882F4B@eigenstate.org> <16994869310.bb41deF.62237@composer.9fans.topicbox.com> In-Reply-To: Date: Thu, 9 Nov 2023 21:24:07 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=16995830471.be29.126202 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 3a58787e-7f70-11ee-802f-1783232d11b0 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UN2E1YmIzY2RlNTBhOGE5YS1NZmU0YmU2Y2I0NzI1MzdlYTM1ZjFk?= =?UTF-8?B?MTk1Pg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> From: "ibrahim via 9fans" <9fans@9fans.net> List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:Mfe4be6cb472537ea35f1d195:1:GOkJEOXdjljM90UPD8HXOI3ZQicNmzbjnQH6ub8lWac --16995830471.be29.126202 Date: Thu, 9 Nov 2023 21:24:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Some time ago I wrote an email to p9f for registration of a user account in= the contrib folder but that mail never got delivered. Otherwise I would re= gularly place a binare image for x86 for testing the effect of changes I ma= de to the kernel and userland regarding performance. Regarding code samples : I'm using plan9 compilers as backends for my own C= with Objects dialect which gets preprocessed and generates code understood= by the plan9 compilers. My fork of plan9 isn't of general interest cause i= ts goal is to provide a small (currently 4,8 MB) graphical terminal which c= onnects to a closed area network server over tcp/ip for education purposes.= I avoid using 9p where possible to improve the performance of the system w= hich hasn't the goal to be a network operating system like plan9. I like th= e "everything is a file" model but implemented it in form of a block orient= ed memory file system using shared memory segments which leads to a great p= erformance boost cause interprocess communication between processes on a si= ngle machine are realized in the form of file exchange without any form of = translation to 9p and transfer over bytestreams which is surely necessary f= or a networking operating system like plan9 but not for an isolated machine= which has only a proprietary tcp/ip protocol connection to a well defined = server. For kernel files in /dev I wrote wrapper processes which transfer c= hanges into the shared memory file system realm.=20 In the first versions I used locks (especially lock and canlock) with polli= ng in slave processes. For the next version I tried to avoid polling by usi= ng qlocks rsleep and rwake but while testing under 9vx, qemu and on bare me= tal the above mentioned problems appeared. When a process using Rendez and = QLock structures in a shared memory segment called rwake more than once dur= ing its executing cycle first 9vx crashed than qemu crashed in an absurd wa= y and also the bare metal version crashed. The reasoning behind this thread is only informing others about possible pr= oblems I encountered. I don't need a solution I already have a working work= around using simple locks. My code would be of no benefit for other plan9 u= sers or developers but if there is interest for investigating the problem I= can write a simplified example which reproduces this behavior.=20 P.S. The shared memory is not attached with segattach but provided from rfo= rk/exec which could be one reason behind this problem. rfork copies the par= ent segments into the list which can be accessed using proc/n/segment and u= sing segments in this way is different from using segments by using segatta= ch in many ways.=C2=A0 Perhaps this is also the reason for the crashes. On Wednesday, 8 November 2023, at 10:08 PM, ori wrote: > A complete snippet to reproduce this may be useful. That said, I have code that uses qlock and rendez heavily with no sleeps, and have not had any issues on 9front. I also didn't have problems using qlock rendez without the combination of s= hared memory and rfork based shared segments. On Thursday, 9 November 2023, at 4:16 AM, Lucio De Re wrote: > I am sincerely hoping you intend to publish your efforts that certainly sound very promising. I intend shareing at least a binary version of my forked simple version aft= er porting scintilla to my gui system cause right my system consists mainly= of a viewer for a simplified markup which is used to present lecture notes= , sound and animations (proprietary format). An editor is my minimal expectation towards myself before making such an im= age available for discussions on this mailing list.=20 ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7a5bb3cde50a8a9a-Mfe4be= 6cb472537ea35f1d195 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --16995830471.be29.126202 Date: Thu, 9 Nov 2023 21:24:07 -0500 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some time ago I wrote an email to p9f for regi= stration of a user account in the contrib folder but that mail never got de= livered. Otherwise I would regularly place a binare image for x86 for testi= ng the effect of changes I made to the kernel and userland regarding perfor= mance.

Regarding code samples : I'm us= ing plan9 compilers as backends for my own C with Objects dialect which get= s preprocessed and generates code understood by the plan9 compilers. My for= k of plan9 isn't of general interest cause its goal is to provide a sma= ll (currently 4,8 MB) graphical terminal which connects to a closed area ne= twork server over tcp/ip for education purposes. I avoid using 9p where pos= sible to improve the performance of the system which hasn't the goal to= be a network operating system like plan9. I like the "everything is a= file" model but implemented it in form of a block oriented memory fil= e system using shared memory segments which leads to a great performance bo= ost cause interprocess communication between processes on a single machine = are realized in the form of file exchange without any form of translation t= o 9p and transfer over bytestreams which is surely necessary for a networki= ng operating system like plan9 but not for an isolated machine which has on= ly a proprietary tcp/ip protocol connection to a well defined server. For k= ernel files in /dev I wrote wrapper processes which transfer changes into t= he shared memory file system realm.

In th= e first versions I used locks (especially lock and canlock) with polling in= slave processes. For the next version I tried to avoid polling by using ql= ocks rsleep and rwake but while testing under 9vx, qemu and on bare metal t= he above mentioned problems appeared. When a process using Rendez and QLock= structures in a shared memory segment called rwake more than once during i= ts executing cycle first 9vx crashed than qemu crashed in an absurd way and= also the bare metal version crashed.

The = reasoning behind this thread is only informing others about possible proble= ms I encountered. I don't need a solution I already have a working work= around using simple locks. My code would be of no benefit for other plan9 u= sers or developers but if there is interest for investigating the problem I= can write a simplified example which reproduces this behavior.

P.S. The shared memory is not attached with segattac= h but provided from rfork/exec which could be one reason behind this proble= m. rfork copies the parent segments into the list which can be accessed usi= ng proc/n/segment and using segments in this way is different from using se= gments by using segattach in many ways.  Perhaps this is also the reas= on for the crashes.

On Wednesday, 8 Novemb= er 2023, at 10:08 PM, ori wrote:
A com= plete snippet to reproduce this may be useful. That said, I have code that uses qlock and rendez heavily with no sleeps, and have not had any issues on 9front.
I = also didn't have problems using qlock rendez without the combination of= shared memory and rfork based shared segments.

On Thursday, 9 November 2023, at 4:16 AM, Lucio De Re wrote:
I am sincerely hoping you intend to publish yo= ur efforts that certainly sound very promising.
I intend shareing at= least a binary version of my forked simple version after porting scintilla= to my gui system cause right my system consists mainly of a viewer for a s= implified markup which is used to present lecture notes, sound and animatio= ns (proprietary format).
An editor is my minimal expectatio= n towards myself before making such an image available for discussions on t= his mailing list.



=
= --16995830471.be29.126202--