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