[9fans] alt and chanfree
Hi all,
I'm doing something like the following to synchronize a bunch of
coroutines.
Everything goes fine while the different threads are working (and are
regularly sending over their respective channel). However, as soon as
one terminates and calls chanfree(), the next call to alt() fails (as
in I get a pagefault message). I can tell because if I never call
chanfree() I never hit that error.
Now in this simplified version I haven't shown that I in fact actually
dynamically reorganize the Alt * (adding/removing an Alt everytime a
caller starts/terminates) so it's totally possible I messed up there.
Before I dig deeper to find out what I'm doing wrong in my Alt *,
I wanted to make sure that I'm globally doing the right thing, i.e. if
it's ok and even recommended to free the Channel as soon as the thread
that was sending on it does not need it anymore.
Can anyone please confirm that?
Thanks,
Mathieu
static void
caller(void *arg)
{
struct Params{ Torrent *tor; Peer *peer; Channel *c;} *params;
uchar chanmsg[1];
params = arg;
// in callerworks() we send() on params-c at various points to
synchronize, all goes well.
callerworks(params-tor, params-peer, params-c);
chanmsg[0] = 0;
send(params-c, chanmsg);
// peer is done working now
chanfree(params-c);
}
void
callers(void *arg)
{
Torrent *tor = arg;
Peer *peer;
uchar m[1];
int i;
int n;
Alt *a;
struct Params{Torrent *tor; Peer *peer; Channel *c;} *params;
a = emalloc((MAXPEERS+1)*sizeof(Alt));
for (i = 0; iMAXPEERS; i++){
a[i].v = m;
a[i].c = chancreate(sizeof(m), 0);
a[i].op = CHANRCV;
// prepare params for the thread
peer = emalloc(sizeof(Peer));
params = emalloc(sizeof(struct Params));
params-tor = tor;
params-peer = peer;
params-c = a[i].c;
threadcreate(caller, params, STACK);
}
a[MAXPEERS].v = nil;
a[MAXPEERS].c = nil;
a[MAXPEERS].op = CHANEND;
for(;;){
n = alt(a);
if(n 0)
error(with alt);
if (m[0] == 0){
// a caller has terminated
dosomestuff()
}
}
}
Re: [9fans] alt and chanfree
On 14 September 2010 09:57, Mathieu Lonjaret mathieu.lonja...@gmail.com wrote:
for(;;){
n = alt(a);
if(n 0)
error(with alt);
if (m[0] == 0){
// a caller has terminated
dosomestuff()
shouldn't you nil out the appropriate part of the alt
array here? i.e. a[n].c = nil
otherwise you'll be alting on a freed chan which
must be bad.
Re: [9fans] alt and chanfree
That's exactly the sense of my question, thanks.
I didn't see in the man page if I should do that sort of cleaning up or
not, it just says that the channel can be freed from either side. so I
wasn't sure in what state alt() is expecting the Alt entries to be at
all time.
I'll try it out later today, thanks.
Cheers,
Mathieu
---BeginMessage---
On 14 September 2010 09:57, Mathieu Lonjaret mathieu.lonja...@gmail.com wrote:
for(;;){
n = alt(a);
if(n 0)
error(with alt);
if (m[0] == 0){
// a caller has terminated
dosomestuff()
shouldn't you nil out the appropriate part of the alt
array here? i.e. a[n].c = nil
otherwise you'll be alting on a freed chan which
must be bad.
---End Message---
Re: [9fans] alt and chanfree
On Tue Sep 14 06:11:35 EDT 2010, mathieu.lonja...@gmail.com wrote: That's exactly the sense of my question, thanks. I didn't see in the man page if I should do that sort of cleaning up or not, it just says that the channel can be freed from either side. so I wasn't sure in what state alt() is expecting the Alt entries to be at all time. isn't that what chanclose()/chanclosing() is for? - erik
Re: [9fans] alt and chanfree
Maybe. Lookman gives me nothing, which page is it please? Mathieu ---BeginMessage--- On Tue Sep 14 06:11:35 EDT 2010, mathieu.lonja...@gmail.com wrote: That's exactly the sense of my question, thanks. I didn't see in the man page if I should do that sort of cleaning up or not, it just says that the channel can be freed from either side. so I wasn't sure in what state alt() is expecting the Alt entries to be at all time. isn't that what chanclose()/chanclosing() is for? - erik ---End Message---
Re: [9fans] alt and chanfree
On Tue Sep 14 09:28:48 EDT 2010, mathieu.lonja...@gmail.com wrote: Maybe. Lookman gives me nothing, which page is it please? thread(2). you may have to update your thread library/man pages. chanclosing is recent. - erik
Re: [9fans] alt and chanfree
Ah, I indeed use an old iso with 9vx, that might be it. thanks, Mathieu ---BeginMessage--- On Tue Sep 14 09:28:48 EDT 2010, mathieu.lonja...@gmail.com wrote: Maybe. Lookman gives me nothing, which page is it please? thread(2). you may have to update your thread library/man pages. chanclosing is recent. - erik ---End Message---
Re: [9fans] alt and chanfree
On Tue, Sep 14, 2010 at 3:27 PM, Mathieu Lonjaret mathieu.lonja...@gmail.com wrote: isn't that what chanclose()/chanclosing() is for? - erik Not at all. Chanclose and chanclosing are to be used while the channel still exists. A closed channel is not a freed channel. Close/closing are useful for synchronizing the cleanup but no other operation should be done on a channel after it has been freed because the channel no longer exists. -- - curiosity sKilled the cat
Re: [9fans] alt and chanfree
isn't that what chanclose()/chanclosing() is for? - erik Not at all. Chanclose and chanclosing are to be used while the channel still exists. A closed channel is not a freed channel. Close/closing are useful for synchronizing the cleanup but no other operation should be done on a channel after it has been freed because the channel no longer exists. of course i ment using chanclose as the first step. the thread running the alt can free the closed channel. - erik
[9fans] c compiler bug
it appears that ?c do not properly do structure
assignment if the structure is packed.
i've included a patch just for 8c and a sample
program that generates two packed assignment
warnings with the modified compiler.
feedback appreciated unless it's don't do that.
if this looks entirely reasonable, i'll submit a patch
for all the compilers.
- erik
---
; diffy -c /sys/src/cmd/8c/cgen.c
/n/dump/2010/0914/sys/src/cmd/8c/cgen.c:1824,1829 -
/sys/src/cmd/8c/cgen.c:1824,1836
gins(ACLD, Z, Z);
gins(AREP, Z, Z);
gins(AMOVSL, Z, Z);
+ if(x = w SZ_LONG-1){
+ warn(n, packed assignment);
+ gins(AMOVL, nodconst(x), nod3);
+ // gins(ACLD, Z, Z);
+ gins(AREP, Z, Z);
+ gins(AMOVSB, Z, Z);
+ }
if(c 4) {
gins(APOPL, Z, nod3);
reg[D_CX]--;
---
#include u.h
#include libc.h
#pragma pack on
typedef struct S S;
struct S
{
uchar a;
ushort b;
uintc;
};
#pragma pack off
S
func(void)
{
S s;
s.a = 1;
s.b = 2;
s.c = 3;
return s;
}
void
main(void)
{
S s, t;
memset(s, 0xff, sizeof s);
print(sizeof s = %d\n, sizeof s);
s = func();
memset(t, 0xff, sizeof t);
t = s;
print(a=%d b=%d c=%d\n, t.a, t.b, t.c);
exits(nil);
}
Re: [9fans] c compiler bug
since it's a pragma, i suppose it shouldn't affect correctness. still, i don't know how far down this route i'd like to go. i'd actually plump for disabling the pragma. (realistically, most of the original reasons for it have vanished, since so much stuff is in gcc or c++.) still, what are you using it for?
Re: [9fans] 9vx mk install chokes on gs
2010/9/12 yy yiyu@gmail.com: 2010/9/12 ron minnich rminn...@gmail.com: Ah. It was 256 MB but Yiyus changed it 8 weeks ago to 64MB. Why? Sorry about that. It was after updating all the a/ files from the .ed scripts. It looks like I did not pay enough attention to mem.ed. There were other changes that could be causing problems too. I'm currently having another look at all the stuff in a/. It could take some time, but I will fix it. In the meantime, the old mem.h will probably work just fine. The problem was in mem.ed. I have changed it and think it should work well now, but the problem was in the original russ' file and all this stuff is a bit over me. When you have some time, could you please have a look at it and/or do some testing? For the moment I modified mem.ed but not mem.h (just in case). To regenerate mem.h, run something like this from src/9vx/a: ./AUTOGEN -r ~/sysfromiso/ /sys/src/9/pc/mem.h Thanks In other new: kfs support is in bootboot now, I'm currently running 9vx from a kfs file. It feels good. -- - yiyus || JGL . 4l77.com
Re: [9fans] c compiler bug
I've a need for the pragma. We're using it. That's how I found the problem. bwc On Sep 14, 2010, at 4:20 PM, Charles Forsyth wrote: since it's a pragma, i suppose it shouldn't affect correctness. still, i don't know how far down this route i'd like to go. i'd actually plump for disabling the pragma. (realistically, most of the original reasons for it have vanished, since so much stuff is in gcc or c++.) still, what are you using it for?
Re: [9fans] c compiler bug
On Tue, Sep 14, 2010 at 1:59 PM, Brantley Coile brant...@coraid.com wrote: I've a need for the pragma. We're using it. That's how I found the problem. bwc I can tell you that people who use this sort of thing at some point discover it's not really what they wanted. They end up writing functions to more or less do the same thing. I'm not sure you want to go down this path. Example: Xen 2 used __attribute__ packed heavily, realized at some point it was a bad idea, and took another path. ron
