On 11/10/23, ibrahim via 9fans <9fans@9fans.net> wrote:
> [ ... ]
>
> 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
>
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
On 11/9/23, ibrahim via 9fans <9fans@9fans.net> wrote:
>
> If there is interest for reproducing the exact circumstances I can write a
> small example app which involves different processes accessing the same
> shared memory segments which are inherited by the rfork methods.
>
I assume that such an
Thanks for your reply. This behavior only appeared while using shared memory in
form of segments. I already solved this problem by exchanging qlock, qunlock by
lock (canlock). I also didn't have any problems while using other forms of
memory constellations but while using shared memory segments
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.
Quoth ibrahim via 9fans <9fans@9fans.net>:
> I have a function chan_send in which :
> chan_send (...) {
> qlock()
> rwakeup(...)
>
I have a function chan_send in which :
chan_send (...) {
qlock()
rwakeup(...)
qunlock()
}
If two such chan_send functions are called without a "task-switch" 9vx crashes.
A work around for this problem is to place a sleep(0) after qunlock to enforce
a task-switch
chan_send(...) {
qlock()
