Re: [boost] gil::io "non-review" (was: [gil] Can not open test.jpg)

Subject: Re: [boost] gil::io "non-review" (was: [gil] Can not open test.jpg)
From: Christian Henning (chhenning_at_[hidden])
Date: 2010-03-24 11:41:45

Hi Phil, first of all thanks for raising these issues. I believe it's
very helpful for my submission.

>> Does that mean I have to call setjmp everytime before I call libjeg
>> function? This way the function that calls setjmp would not have been
>> terminated.
>
> Your choices are:
>
> 1. setjmp() in each function (scope?) that calls into libjpeg.  That's nasty
> because setjmp(), IIRC, is detected by the compiler and prevents some
> optimisations.  It's relatively non-intrusive in your code though.

In my opinion this is the best option I have right now.

>
> 2. setjmp() once, and make sure that that is in a scope that contains all
> the calls.  This means turning your code inside out, but it's not impossible
> because - as we've noted - you never leave a jpeg file open and return to
> the user code, i.e. the setjmp() can happen soon after the user calls into
> your code.  I don't think that destructors will not be called when longjmp()
> "pops" the stack, so you need to be careful about what types you use.

This would turn my code into an ugly huge switch statement, with a lot
of code repetition. I rather not do that.

>
> 3. (deleted - idea too horrible to share.)

Don't even wanna know. ;-)

>
> 4. Try to throw an exception from the error handler.  This would be ideal,
> if you could be sure that the exception would propagate through the C code.
>  I believe that gcc has an option to control that.  I have a feeling that it
> is enabled for some libraries in Debian precisely to support this sort of
> thing.  I know nothing about other compilers, and even on Linux it's
> probably not reasonable to expect that the user will use a libjpeg compiled
> in this way.

I agree this would be support nightmare. We all know that the user
wants something workable out-of-box.

>
> 5. (Grasping at straws) run libjpeg in a co-routine, err, not sure exactly
> how that would work, but something about an extra stack...

I'm already drowned. Maybe someone else on this mailing list can go
into more details.

>
> 6. This is what I'd really like to see: copy the libjpeg source into your
> project, and then do (4).  You could do some other tidying-up at the same
> time.

This is only possible if I have someone who is willing to put the time
and effort in. I don't have that right now. Leaving for loooooooong (
2 months ) vacation soon. Also, do you know whether or not libjpeg
continued?

What I could see is to have a separate project that provides an
"updated" libjpeg source. For such users we could provide a compiler
symbol to compile optimized code. I'll keep this option in mind.

>
>
> My recollection is that one of the other libraries also had a setjmp error
> handler, but that it could be configured to instead return error codes while
> libjpeg can't.  Not sure if that's accurate though.

Do you mean libpng? I believe I have to update my code for png, as well.

Thanks again,
Christian