[GEM-dev] pix_share broken several ways

[IOhannes m zmoelnig]

chris clepper wrote:
> Hi
> 
> I can no longer get pix_share to work the way I had originally written
> the object.

i admit i changed it to not crash anymore on my machines :-)

> 
> First, the csize selection does not work.  On OSX it is fixed to 2 and
> neither 4, r, R, or RGBA changes it.

this is very weird.
the only reason i can imagine for this is that 
imageStruct.setCsizeByFormat(GL_RGBA) returns something very wrong (like 
enforcing it to be ycbcr and ignoring the argument)...but i doubt it


> 
> Second, after the shm buffer is set there is no way to change the
> size.  I get endless amounts of this:
> 
> pix_share_*: 2048x768x2: 3145728
> pix_share_*: someone was faster: only got 1572864 bytes instead of 3145728
> pix_share_*: shm:: id(131072) segsz(1572884) cpid (23205) mem(0x101F6000)

you mean, you get this error message each render-cycle?
or do you repeatedly trigger a "set" message to [pix_share_write]?

> 
> Someone was faster?  WTF?  I get that even after deleting the
> pix_share_write object and recreating it.  Creating the object should
> set up whatever I tell it to set up.

the difference (iirc) between your original version and the current one 
is, that both [pix_share_read] and [pix_share_write] set up the shared 
memory segment, whichever is faster (read: created earlier)
so "someone was faster" means, that another object (e.g. 
[pix_share_read]) has already set up an shm-segment with the same id.
if the shm-segment is already there, then none of the objects try to 
resize it but instead use what is already there.

in order to free the shm-segment you will have to destroy ALL references 
to it (read: all [pix_share_read] and [pix_share_write] objects 
referencing the same segment)

> 
> Finally, after setting up one shm buffer at an address I can no longer
> create one at any other address.  I get this message:
> 
> pix_share_*: 2048x768x2: 3145728
> error: pix_share_*: couldn't get shm_id: error 12
> 
> Again, I'm telling pix_share_write to create a shm buffer at a certain
> address and of a certain size.  Why would it refuse to do this?

i'll have a look at that (i cannot remember having that problem)

what comes to my mind is that the symbolic/numeric id exposed given is 
evaluated incorrectly.
could you please give the exact arguments of the [pix_share*] objects 
you try to create?

> 
> The code I checked in did not do this.  I cannot figure out what the
> intended function of some of the code is and do not know how to make
> changes other than reverting back to what I know works and continuing
> from that point.

it would be great if we could make the current version running on your 
system instead of reverting it to a version that is known to crash on 
other systems. (in the end i hope it will work on all systems)



mfg.adsr.
IOhannes