Suggestion: WP Super Cache could calculate a unique semaphore id

  • tigertech

    (@tigertech)


    15 years, 7 months ago

    Currently, the semaphore ID used by WP Super Cache is fixed at 5419 unless the user edits it. This causes problems on shared hosting: it only works for one user per server, and the second user has to modify it.

    What’s worse, it might work when someone initially installs WP Super Cache, but start failing after the server is restarted if another user gets “first grab” at the semaphore after the restart. (I’ve seen this happen.)

    I’d like to suggest something like the patch at:

    http://www.tigertech.net/patches/wp-supercache-unique-semaphore-id.patch

    It automatically chooses a unique semaphore id based on the cache directory path, which should be unique per user on the server. This should mean that two users on the same server can use it without conflicts.

    Note that this is untested on Windows (it’s only been tested on Linux). In particular, before using it, someone should test whether the allowed range of the id passed to the sem_get function is (at least) 31 bits, as it is on Linux.

Viewing 4 replies - 1 through 4 (of 4 total)
  • Murmatron 2

    (@murmatron-2)

    15 years, 7 months ago

    Maybe I’m missing something, but I don’t quite get the point of the semaphore at all.

    The wp-cache filenames have an md5 with $_SERVER[‘HTTP_HOST’] and supercache files are saved in a structure based on HTTP_HOST so there is no inherent potential for different VHOSTS to be in contention. The scenario you describe arises purely from the use of the semaphore.

    If the cache_writers_entry/exit were removed completely it seems to me that the worst that can happen is that the fopens fail because of blocking caused by simultaneous requests to the same HOST/URI, the cache file isn’t written for the second request but both clients get the content anyway.

    Thread Starter tigertech

    (@tigertech)

    15 years, 7 months ago

    the worst that can happen is that the fopens fail

    The files aren’t opened in exclusive mode, so the fopens won’t block; there would be nothing stopping two processes from both opening the same file, then both writing to it (with both fopens happening before either process calls fputs).

    This often wouldn’t cause problems because the data would be the same, but if the second fputs less shorter data to the file, there would be trailing junk from the first process left over at the end.

    However, this is all merely descriptive of the current behavior. Maybe donncha can tell us whether the locking is needed for any reason beyond the “prevent two processes from writing to the cache files simultaneously” problem? If not, that problem could probably be fixed by writing to temporary files with unique names per process, removing the need for external locking mechanisms, which would be even better.

    Donncha O Caoimh (a11n)

    (@donncha)

    15 years, 7 months ago

    You’re right. The main reason for the locking is to stop two processes writing to the same file at once.

    Writing to a temporary file and renaming it would solve that problem, but the locking is also used to stop concurrent deletes. See wp_cache_post_change(). Without locking, the cache could be traversed looking for files to delete multiple times. It’s probably not a *huge* problem, so I will look at that when I get time.

    Donncha O Caoimh (a11n)

    (@donncha)

    15 years, 7 months ago

    Tigertech – good idea on the sem_id, I used that idea to modify the default “5419” semaphore in the config file based on the hostname and cache path. Saves on those crc32() calls.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Suggestion: WP Super Cache could calculate a unique semaphore id’ is closed to new replies.