Alan McConnell wrote: > Re "Race Conditions". Unless I am mistaken, mutt is > written as a single, un-threaded process; I believe that > 'me' is (justly) proud of this achievement. So I do > not understand how "two processes" can be involved here.
I see you posted an email about this back on December 19th too.
Although I thought Patrick Shanahan explained it clearly then, and just
now Mark H. Wood did again, I'll take a shot and try to (even) more
verbosely explain what is going on and why it's causing you a problem.
The normal view attachment process for mutt is:
1. Create temp file
2. Launch viewer process
3. Wait for viewer to exit
4. Delete temp file
Assuming you already have a main firefox window running, when you
invoke "firefox -new-tab %s", it does not block. It simply notifies
your main running firefox process to open a tab pointing to %s and then
exits right away. There is now a "race condition". Does mutt delete
the temp file before or after your main firefox process creates the new
tab pointing to it?
Here are two (simplified) tables showing the basic ways this can play
out:
mutt firefox -new-tab main firefox
==== ================ ============
1. Create temp file
2. Launch ff -new-tab %s
3. Notify main firefox
process to create a
new tab %s
4. Exit
5. Creates new tab
pointing to %s
6. Wait for ff -new-tab
to exit
7. Delete temp file %s
-or-
mutt firefox -new-tab main firefox
==== ================ ============
1. Create temp file
2. Launch ff -new-tab %s
3. Notify main firefox
process to create a
new tab %s
4. Exit
5. Wait for ff -new-tab
to exit
6. Delete temp file %s
7. Creates new tab
pointing to %s
8. Error - No such
file
Which one happens depends on which process gets control after step 4:
the main firefox process or mutt. In the first case, main firefox is
able to find the file and read it in. In the second case, main firefox
can't open the file, and you get an error message. In either case,
though, if you go look for the file in /tmp, the file will be gone
because mutt has already deleted it.
There is no completely clean way to fix this, because there is no way to
know how long the main firefox will need %s to be around. If you only
intend to quickly view the file and then close the tab, the best way is
to have mutt sleep after invoking "firefox -new-tab". Try modifying
your .mailcap invocation to:
text/html; firefox -new-tab '%s' & sleep 10; test=........
^^^^^^^^^^^
add this
The idea is that even if the second scenario happens, mutt will just
sleep instead of deleting the temp file. Hopefully the main firefox
will have a chance to run and read that file in before the sleep ends
and mutt deletes the file.
Race conditions are complicated, and this explanation is not complete,
but I hope this helps.
-Kevin
signature.asc
Description: Digital signature
