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 regularly place a binare image for x86 for testing the effect of changes I made 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 its goal is to provide a small (currently 4,8 MB) graphical terminal which connects 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 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 file system using shared memory segments which leads to a great performance boost cause interprocess communication between processes on a single machine are realized in the form of file exchange without any form of translation to 9p and transfer over bytestreams which is surely necessary for 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 changes into the shared memory file system realm. In the 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 qlocks rsleep and rwake but while testing under 9vx, qemu and on bare metal the above mentioned problems appeared. When a process using Rendez and QLock structures in a shared memory segment called rwake more than once during its 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 problems I encountered. I don't need a solution I already have a working workaround using simple locks. My code would be of no benefit for other plan9 users 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 segattach but provided from rfork/exec which could be one reason behind this problem. rfork copies the parent segments into the list which can be accessed using proc/n/segment and using segments in this way is different from using segments by using segattach in many ways. 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 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 your 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 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 image available for discussions on this mailing list. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7a5bb3cde50a8a9a-Mfe4be6cb472537ea35f1d195 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
