async headaches
- From: muppet <scott asofyet org>
- To: gtk-perl-list <gtk-perl-list gnome org>
- Subject: async headaches
- Date: Wed, 05 Jun 2002 22:15:38 -0400
had a devil of a time solving a race condition problem. i'd like your
opinions on what might be a better way to solve this one.
---
i'm creating a file open dialog specifically for images, which shows
some image properties and a thumbnail for each image the user selects in
the file list. i'm using imagemagick's convert and some home-grown
image loading display code for various reasons that aren't all that
relevant.
to the "select-row" signal of the file CList i bound a callback which
would attempt to load and preview the image. so far so good. each time
it runs, it forks a call to convert (via piped open), so there is no
caching of thumbnails (though given time i would like to cache them, but
the regeneration logic is more than i want to deal with right now).
unfortunately, since the loading of the image takes long enough that the
double-click to open feature is now inoperative... the user has to
select the file, wait for the preview to finish loading, and *then*
double click. this is uncool.
so, thinking myself rather clever, i changed the "select-row" callback
to instead install a timeout for a quarter second later to load the
image. then after the user clears the dialog, i remove the timeout,
clean up, and go on my merry way.
except that the program now segfaults because the timeout event got put
on the event queue before i had a chance to remove the timeout, and it's
trying to load an image into a buffer that's already been destroyed.
after a bit of mucking about, i added a field called "dying" to the
parent-to-callback communication hash. if the timeout handler sees the
"dying" flag set it just doesn't do anything. this hack relies on
perl's reference counting to make sure the communication hash even
sticks around long enough to to this job.
this seems to work, but also feels unclean and unsafe.
am i going about this all the wrong way? would simply lengthening the
delay solve the problem? would relying on access and modification times
be sufficient for knowing when to regenerate thumbnails?
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]