can you provide the source file, dont have current 9atom iso handy
and the stuff i found on the net doesnt seem to cut it. however,
i found http://www.quanstro.net/plan9/sleepwake.html which at the
end gives a solution to the problem:
void
dowake(Io *i)
{
i->cond = 1;
wakeup(i);
On Thu Aug 23 05:50:45 EDT 2012, cinap_len...@gmx.de wrote:
> can you provide the source file, dont have current 9atom iso handy
here's the full kernel source: http://ftp.quanstro.net/other/kernel.mkfs.bz2
> and the stuff i found on the net doesnt seem to cut it. however,
> i found http://www.qua
Is there a specific reason of forbidding wstat for 'none' in fossil
(/sys/src/cmd/fossil/9p.c:130,133)?
This causes APE rename() to fail almost always
(/sys/src/ape/lib/ap/plan9/rename.c:43)
Perhaps rename() should be fixed to match mv (/sys/src/cmd/mv.c:/^mv1)
to go around this?
--
- Yaroslav
why? are you counting notes as spurious wakeups? i would not count
them as such because sleep will not return in that case but do a
error jump out of it instead no? what other spurious wakeup sources
are there?
--
cinap
On Thu Aug 23 10:48:13 EDT 2012, yari...@gmail.com wrote:
> Is there a specific reason of forbidding wstat for 'none' in fossil
> (/sys/src/cmd/fossil/9p.c:130,133)?
> This causes APE rename() to fail almost always
> (/sys/src/ape/lib/ap/plan9/rename.c:43)
>
> Perhaps rename() should be fixed to m
On Aug 23, 2012, at 6:27 AM, erik quanstrom wrote:
> any time you use sleep/wakeup, you're going to have to deal with
> spurious wakeups. it does not matter which rendezvous structure
> you use. it doesn't matter if it's shared or not. it's perfectly valid
> for sleep to return for no reason at
> why is this related to ape? if you are none, then you are limited
> as to what you can do on the file server. you may just have an auth problem.
APE implements rename() in terms of wstat or copying. It's just
doesn't try to work around failing wstat (that's perhaps a good thing)
while mv does.
>
> Indeed. One way to catch sleep() errors is to change wakeup() to wake
> *everyone* up.
i was thinking on this and it occurred to me
to make the point by absurdity, consider this approximation
of sleep and wakeup without notes.
void
sleep(Rendez*, void (*)(void*), void
pwait() in port/proc.c would crash in that case if you wake it up
with up->waitq == nil.
or was this ment as a joke?
--
cinap
On Thu Aug 23 11:44:55 EDT 2012, yari...@gmail.com wrote:
> > why is this related to ape? if you are none, then you are limited
> > as to what you can do on the file server. you may just have an auth
> > problem.
>
> APE implements rename() in terms of wstat or copying. It's just
> doesn't try
On Thu Aug 23 11:56:42 EDT 2012, cinap_len...@gmx.de wrote:
> pwait() in port/proc.c would crash in that case if you wake it up
> with up->waitq == nil.
how would that happen? with the approperiate locks held (waitqr),
up->waitq == nil is tested.
> or was this ment as a joke?
no joke.
- erik
> are you sure?
>
> ; touch bz
> ; ratrace -c mv bz bw >[2=1]| grep -v 'Stat|Brk'
you forgot auth/none...
; ratrace -c auth/none mv bz bw >[2=1]| grep -v ' none |Stat|Brk'
209051 mv Wstat 8cfe 0xdfffcef4/"bz" 0xc708 51 = -1 './bw' file does
not exist 1345738572648442848 13457385
pwait():
...
sleep(&up->waitr, haswaitq, up);
lock(&up->exl);
wq = up->waitq;
up->waitq = wq->next; <-- wq == nil, boom! its gone!
up->nwait--;
unlock(&up->exl);
if sleep returns or is spuriously woken up even tho up->waitq == nil.
--
cinap
On Thu Aug 23 12:19:22 EDT 2012, yari...@gmail.com wrote:
> > are you sure?
> >
> > ; touch bz
> > ; ratrace -c mv bz bw >[2=1]| grep -v 'Stat|Brk'
>
> you forgot auth/none...
no, i didn't. ratrace doesn't run if you're none. but that's beside
the point.
as i understand it, yo
> sleep(&up->waitr, haswaitq, up);
>
> lock(&up->exl);
> wq = up->waitq;
> up->waitq = wq->next; <-- wq == nil, boom! its gone!
> up->nwait--;
> unlock(&up->exl);
>
>
> if sleep returns or is spuriously woken up even tho up->waitq == nil.
ah, right. looks
> no, i didn't. ratrace doesn't run if you're none.
try 'ratrace -c auth/none cmd ...' while not being none
and ignore everything preceding Exec "cmd".
> as i understand it, your claim is that mv works as none but ape/rename
> does not and this is because ape/rename uses wstat.
both use wstat o
> try 'ratrace -c auth/none cmd ...' while not being none
> and ignore everything preceding Exec "cmd".
nice trick.
>
> > as i understand it, your claim is that mv works as none but ape/rename
> > does not and this is because ape/rename uses wstat.
>
> both use wstat or copying; what's differen
No. It's not true that all sleeps might return spuriously (it might have
been true in Unix, I can't remember).
It's not true in Plan 9.
On 23 August 2012 12:24, erik quanstrom wrote:
> > sleep(&up->waitr, haswaitq, up);
> >
> > lock(&up->exl);
> > wq = up->waitq;
> > up->
> oh, i thought you were comparing system/library calls, not library function
> vs program. i don't understand that comparison.
it so happens that mv is a program with own idea how to do renames,
and there are no other obvious subject to compare with.
yes, this is what i would'v expected. so who made up that rule
that sleep might spuriously wakeup for no reason or that kernel
code should be written as if sleep/wakeup being troll implementations?
--
cinap
On Thu Aug 23 12:48:17 EDT 2012, charles.fors...@gmail.com wrote:
> No. It's not true that all sleeps might return spuriously (it might have
> been true in Unix, I can't remember).
> It's not true in Plan 9.
is this in /sys/doc/sleep.ps? i think i'm missing it.
- erik
Anybody else noticed ratrace reporting an older errstr?
209051 mv Wstat 8cfe 0xdfffcef4/"bz" 0xc708 51 = -1 './bw' file does
not exist 1345738572648442848 1345738572649648848
I double checked: the wstat definitely returns Eperm on the wire:
Twstat tag 15 fid 1352 stat 'bw' '' '' '' q (ff
On Thu Aug 23 13:11:05 EDT 2012, yari...@gmail.com wrote:
> Anybody else noticed ratrace reporting an older errstr?
yes. i see the same thing. should be using up->syserrstr not up->errstr, i
think.
i took the liberty of removing any system call that's been dead for more than a
decade. :-)
t
On Thu, 23 Aug 2012 12:47:10 EDT Charles Forsyth
wrote:
> No. It's not true that all sleeps might return spuriously (it might have
> been true in Unix, I can't remember).
> It's not true in Plan 9.
It is not that sleep might return spuriously (that is, the
wakeup condition is still false) but t
> the sleeper actually runs -- the above condition is not
> violated as the new process won't be sleeping. But if yet
> another process tries to access the same condition, it will be
> blocked on getting the rendezvous structure lock?
in plan 9 sleep, only 1 sleeper is allowed.
- erik
25 matches
Mail list logo
