aserio changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
eschnett has quit [Quit: eschnett]
vamatya has quit [Ping timeout: 276 seconds]
eschnett has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
jaafar has quit [Ping timeout: 265 seconds]
hkaiser has quit [Quit: bye]
nanashi55 has quit [Ping timeout: 246 seconds]
nanashi55 has joined #ste||ar
vamatya has joined #ste||ar
jaafar has joined #ste||ar
vamatya has quit [Ping timeout: 256 seconds]
david_pfander has joined #ste||ar
jaafar has quit [Ping timeout: 255 seconds]
<heller_>
the thread_stacksize bug seemse to happen on gcc 4.9.4 only. just checked with gcc 4.9.3, everything is fine :/
<simbergm>
heller_: thanks for looking into that
<heller_>
trying with gcc 4.9.4 now
<simbergm>
I wonder if it isn't best just to consider that a known issue for the release, unless you happen to find something obvious quickly
<simbergm>
4.9.4 also seems to be the last release in the 4.9 series...
<heller_>
yeah
<heller_>
I wanna know what's wrong
<simbergm>
sure
<heller_>
there is another issue I am looking into right now ..
<heller_>
when do plan to get the RC out?
<simbergm>
31st jan if all goes well, but it's set a bit conservatively in case we need more time
<simbergm>
my email did go out to the mailing list, right?
<heller_>
but I am leaning more to expected behavior...
<heller_>
the back parcel might arrive before the write handler has been called...
<heller_>
same problem as #2935, i think
<github>
[hpx] sithhell created fix_papi_locking (+1 new commit): https://git.io/vNG3d
<github>
hpx/fix_papi_locking 26c15e2 Thomas Heller: Fixing lock held during suspension in papi counter component
<heller_>
on fire
<github>
[hpx] sithhell opened pull request #3099: Fixing lock held during suspension in papi counter component (master...fix_papi_locking) https://git.io/vNG3b
<zao>
The #gamedev crew loves having those in blittable datablocks on disk, in queues, and shared memory, to make them movable.
<K-ballo>
mmh, technically UB unless there's some sort of array involved?
<K-ballo>
no less UB than indexing into vector, at least
<zao>
So you'd have data blocks with struct Header { RelativePointer<int> foo; RelativePointer<char> bar; }; and a bunch of data before/after with the offsets pointing it out.
<zao>
Always felt a bit janky to me, much like flexible struct members.
<heller_>
K-ballo: sure, but we first check is_bitwise_serializable, and then move on to the pointer
<K-ballo>
doesn't sound like a good idea.. is_bitwise_serializable should be a fallback check
<K-ballo>
user might define serialization for its own trivially copyable type, because reasons, you don't get to skip it
<heller_>
yeah
<K-ballo>
zao: pointers don't point to objects just because they happen to represent the address an object is at
<heller_>
K-ballo: I agree. that's a bug
<heller_>
K-ballo: back in the days, we couldn't reliably detect if someone specified their own serialization function
<heller_>
even worse: each bitwise_serializable type needs to also have the serialize function(s)
<K-ballo>
:/
<K-ballo>
thye do? why?
<heller_>
because the memory layout might be different on the receiving end?
<heller_>
or do we have any guarantees here I am not aware of?
<K-ballo>
so you do want to bypass user's serialization functions
<heller_>
essentially, yes
<K-ballo>
then I doubt you want that to be implicit, due to trivially copyable
<heller_>
which is also probably the reason why all attempts so far failed
<K-ballo>
maybe it should be more declarative
<heller_>
if only we could have binary compatibility
<heller_>
for those types
<K-ballo>
maybe we want types to say these are my members, rather than chaining serialization calls
<heller_>
hmm
<heller_>
yes
<heller_>
but would that solve this issue?
<K-ballo>
it'd give us the ability to say if bitwise serializable and destination compatible memcpy, else synthesize series of individual calls
<K-ballo>
or even memcpy as well, but send a layout description on the side
<heller_>
interesting thought
<heller_>
after all, it all boils down to some sequence of integral types