Re: [9fans] alt and chanfree
I haven't tried chanclose() yet, but setting to nil the freed chan in the alt entry is not really what I wanted since it will make alt() return -1 (better than crashing but not ideal). In any case I found a satisfying workaround in my algorithm to solve that: when a thread is done using a chan, I keep track of it instead of calling chanfree(), and instead of allocating a new chan/alt when creating a new thread, I simply reuse one of the previously abandonned ones (if any is available). And I'll just free them all when the program terminates. Thanks to all, Mathieu ---BeginMessage--- 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 ---End Message---
Re: [9fans] c compiler bug
It's the compiler's prerogative to decide just how the fields should be packed so therefore, the construct is never portable. it's worse than that: you can't use them to access hardware structures, since (especially if values are misaligned) there's no guarantee that the generated code will access them as the hardware requires. you can use them to access existing software structures from another system, which is why they were added originally, but even then i'm sceptical, because misaligned accesses only work on x86 (and then only if the kernel doesn't set the alignment trap). on sparc, arm, and powerpc, you'll get a trap. it was much the same with gcc last time i checked (but that was some time ago). i remember seeing that linux on arm handles misaligned traps by interpreting code in the kernel. (it wasn't for the gcc equivalent of pragma packed, but to support rotten code from x86.) either way, this seems unlikely to encourage good performance. it might be better to write a sed or sam script to transform incoming structure definitions into uchar x[] style.
Re: [9fans] c compiler bug
Example: Xen 2 used __attribute__ packed heavily, realized at some point it was a bad idea, and took another path. at the time, gcc on arm didn't generate the code to fetch or store the values a byte at a time, which probably came as a surprise. i haven't tried it myself with gcc more recently.
Re: [9fans] c compiler bug
actually, it gets worse. i looked up the stuff for ARM, and it was much as i expected, but they also pointed out another problem, obvious in retrospect. you say you want structure assignments to work, or at least not fail. fair enough, but what about this: S s; int *p = s.c; *p = 1; int x = *p; the point is that in general given an int*, there's no way to know that the target is misaligned. ARM thoughtfully provides a __packed attribute, as in __packed int *p; and then an appropriate sequence of byte-by-byte loads (or stores) will be used to access it, but a normal int* will produce an alignment trap.
Re: [9fans] alt and chanfree
On 15 September 2010 09:15, Mathieu Lonjaret mathieu.lonja...@gmail.com wrote: I haven't tried chanclose() yet, but setting to nil the freed chan in the alt entry is not really what I wanted since it will make alt() return -1 (better than crashing but not ideal). it wouldn't return -1 (assuming there are at least some valid channels in the alt array) if you set the op to CHANNOP as well as setting c to nil.
Re: [9fans] alt and chanfree
Ah indeed, thank you. ---BeginMessage--- On 15 September 2010 09:15, Mathieu Lonjaret mathieu.lonja...@gmail.com wrote: I haven't tried chanclose() yet, but setting to nil the freed chan in the alt entry is not really what I wanted since it will make alt() return -1 (better than crashing but not ideal). it wouldn't return -1 (assuming there are at least some valid channels in the alt array) if you set the op to CHANNOP as well as setting c to nil. ---End Message---
Re: [9fans] c compiler bug
and then an appropriate sequence of byte-by-byte loads (or stores) will be used to access it, for static references such as s.c there's an optimisation that allows the nearest aligned values to be loaded, shifted masked, and or'd together to save accesses by byte, but that doesn't seem to be possible for an unaligned pointer reference.
[9fans] marvell/highpoint ahci
i just pushed out some minor changes to contrib quanstro/sd that add support for marvell/highpoint ahci. it's not clear that 6.0gbps operation is properly supported, as i don't have a sata iii hard drive yet. performance about half that of the native controller. there seems to be a large command-issue latency as even with a fairly good ssd, i can only push about 15000 512-byte iops. the native ahci (3.0gbps) controller can do over 4. the card i have presents a single-port ide controller, which is currently ignored since there is no pata connector, and is thus difficult to test. - erik
