[GEM-dev] pix_share broken several ways

[IOhannes m zmoelnig]

chris clepper wrote:
> On 6/8/06, *IOhannes m zmoelnig* <zmoelnig at iem.at 
> <mailto:zmoelnig at iem.at>> wrote:

> I put a simple if statement in pix_share_write to replace the 
> imageStruct call and it works fine.  I think setCSizeByFormat() might 
> not be working on the Mac.  All those #ifdefs are hard to read!  I will 
> try to replace it with a single one for __APPLE__ and see if that helps. 

i agree that it might be better to just have one big #ifdef _APPLE__ 
#endif instead of 4 of them
would you change it or should i do it? (and honestly, i much prefer an 
#ifdef over an #ifndef for readability)

> 
>     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) 
> 
> 
> This is the tricky part of these objects to deal with.  You can either 
> allow the user to whatever they want when setting up shm or put in a 
> check to help keep them from doing something which might crash or become 
> unusable.  My original thinking was that anyone using these objects 
> would have to really know what they are doing to set them up properly 
> and to just let them do it. 

i see.
since there were no help-patches, you were the only person who knew 
exactly what the objects were doing. when i first tried to use them they 
just plain crashed which i found a bit "unusable".
so i was kind of a burnt child and tried to make it nice.

that if pd is meant to be a real programming language then the user must 
be able to crash the computer :-)

> 
> The alternative idea to put checks in place to keep from crashing/etc 
> should probably be even more complete.  Rather than locking the shm per 
> ID, pix_share_write should allow for resizing and the pix_share_read 
> objects would have to be alerted to this change.   In my initial testing 
> (on OSX only) changing the size of the shm region for a single ID 
> worked.  If this is not the case on Linux then some other solution will 
> have to be figured out.


actually i never really tried to do change the size, but i am not sure 
how this would be done (i haven't found a way to resize an already 
existing shared memory segment as long as processes are attached to it)

so we might have to notify all related objects that they should detach 
themselves (which i don't know how to do)

remember that the given size is just the amount of memory reserved.
you can send images of any size via this segment, as long as the data 
fits into the reserved memory.
so i am not sure whether there is a realy need for resizing on the fly.

one possibility that comes to my mind is, that we could use 2 portions 
of shared memory: one fixed-sized segment which just holds the key to 
the actual data segment (and probably all the meta-data such as 
dimensions,...)

however, i am not sure whether this all would work with multiple 
[pix_share_write]s accessing the same memory (which i think is a nice 
feature, though i don't have an application at hand)


> 
> I agree.  I originally wrote the object from some code Chris Klippel 
> used on Linux back in the old days of jMax video and it worked fine on 
> OSX back then too.  I could have made a mistake or the Linux spec could 
> have changed since though. 

i don't think so.
most likely it just crashed because i didn't know how to use the objects.

> 
> I made some hacks since I need the code to work right then, so now it's 
> time for real fixes.  The first thing to figure out is how we want the 
> object to behave in end use.  Do we allow for any settings or do we 
> confine the objects even further than they are now? 

hmm. one of my ideas was to export the shared-memory thing into a 
different set of objects (not related to Gem!)
then a pointer to this memory would be passed to the read/write objects.
this way they would not need to know anything about shared memory and it 
would allow for the biggest flexibility.




mfg.asd.r
IOhannes