my $wikilock;
-sub lockwiki (;$) { #{{{
- my $wait=@_ ? shift : 1;
+sub lockwiki () { #{{{
# Take an exclusive lock on the wiki to prevent multiple concurrent
# run issues. The lock will be dropped on program exit.
if (! -d $config{wikistatedir}) {
}
open($wikilock, '>', "$config{wikistatedir}/lockfile") ||
error ("cannot write to $config{wikistatedir}/lockfile: $!");
- if (! flock($wikilock, 2 | 4)) { # LOCK_EX | LOCK_NB
- if ($wait) {
- debug("wiki seems to be locked, waiting for lock");
- my $wait=600; # arbitrary, but don't hang forever to
- # prevent process pileup
- for (1..$wait) {
- return if flock($wikilock, 2 | 4);
- sleep 1;
- }
- error("wiki is locked; waited $wait seconds without lock being freed (possible stuck process or stale lock?)");
- }
- else {
- return 0;
- }
+ if (! flock($wikilock, 2)) { # LOCK_EX
+ error("failed to get lock");
}
return 1;
} #}}}
rev => $info->{"revno"},
user => $user,
committype => "bzr",
- when => time - str2time($info->{"timestamp"}),
+ when => str2time($info->{"timestamp"}),
message => [@message],
pages => [@pages],
};
}
my $check_commit_hook="";
+ my $pre_exec="";
if ($config{post_commit}) {
# Optimise checking !commit_hook_enabled() ,
# so that ikiwiki does not have to be started if the
# the benefit of this optimisation.
$check_commit_hook=<<"EOF";
{
- int fd=open("$config{wikistatedir}/commitlock", O_CREAT | O_RDWR);
+ int fd=open("$config{wikistatedir}/commitlock", O_CREAT | O_RDWR, 0666);
if (fd != -1) {
if (flock(fd, LOCK_SH | LOCK_NB) != 0)
exit(0);
}
EOF
}
+ elsif ($config{cgi}) {
+ # Avoid more than one ikiwiki cgi running at a time by
+ # taking a cgi lock. Since ikiwiki uses several MB of
+ # memory, a pile up of processes could cause thrashing
+ # otherwise.
+ $pre_exec=<<"EOF";
+ {
+ int fd=open("$config{wikistatedir}/cgilock", O_CREAT | O_RDWR, 0666);
+ if (fd != -1)
+ flock(fd, LOCK_EX);
+ }
+EOF
+ }
$Data::Dumper::Indent=0; # no newlines
my $configstring=Data::Dumper->Dump([\%config], ['*config']);
exit(1);
}
+$pre_exec
execl("$this", "$this", NULL);
perror("exec $this");
exit(1);
was earlier added to edit links.
* tag: Normalize tagbase so leading/trailing slashes in it don't break
things.
+ * bzr: Fix dates for recentchanges.
+ * Avoid multiple ikiwiki cgi processes piling up, eating all memory,
+ and thrashing, by making the cgi wrapper wait on a cgilock.
+ If you had to set apache's MaxClients low to avoid ikiwiki thrashing your
+ server, you can now turn it up to a high value.
+ * Stop busy-waiting in lockwiki, as this could delay ikiwiki from waking up
+ for up to one second. The bailout code is no longer needed after above
+ change.
+ * Remove support for unused optional wait parameter from lockwiki.
-- Joey Hess <joeyh@debian.org> Thu, 06 Nov 2008 16:01:00 -0500
--- /dev/null
+Using bzr, the dates for changes on the RecentChanges page all start
+slightly before the Unix epoch.
+
+Changing line 249 of bzr.pm from
+
+` when => time - str2time($info->{"timestamp"}),`
+
+to
+
+` when => str2time($info->{"timestamp"}),`
+
+fixed this for me.
+
+> Weird, I wonder why it was written to return an absolute time like that
+> in the first place? Can't have ever been right. Fixed, thanks. --[[Joey]]
+> [[done]]
>>> When a new language is added to `po_slave_languages`, a rebuild is
>>> triggered, and all missing PO files are created and checked into
>>> VCS. An unpriviledged wiki user can not add a new language to
->>> `po_slave_languages`, though. One could thing of adding the needed
+>>> `po_slave_languages`, though. One could think of adding the needed
>>> interface to translate a page into a yet-unsupported slave
>>> language, and this would automagically add this new language to
>>> `po_slave_languages`. It would probably be useful in some
>>>> I guess that if the template modification is made, it will list those
>>>> languages on the page, and if a translation to a language is missing,
>>>> the link will allow creating it?
+>>>>
+>>>>> Any translation page always exist for every supported slave
+>>>>> language, even if no string at all have been translated yet.
+>>>>> This implies the po plugin is especially friendly to people who
+>>>>> prefer reading in their native language if available, but don't
+>>>>> mind reading in English else.
+>>>>>
+>>>>> While I'm at it, there is a remaining issue that needs to be
+>>>>> sorted out: how painful it could be for non-English speakers
+>>>>> (assuming the master language is English) to be perfectly able
+>>>>> to navigate between translation pages supposed to be written in
+>>>>> their own language, when their translation level is most
+>>>>> often low.
+>>>>>
+>>>>> (It is currently easy to display this status on the translation
+>>>>> page itself, but then it's too late, and how frustrating to load
+>>>>> a page just to realize it's actually not translated enough for
+>>>>> you. The "other languages" loop also allows displaying this
+>>>>> information, but it is generally not the primary
+>>>>> navigation tool.)
+>>>>>
+>>>>> IMHO, this is actually a social problem (i.e. it's no use adding
+>>>>> a language to the supported slave ones if you don't have the
+>>>>> manpower to actually do the translations), that can't be fully
+>>>>> solved by technical solutions, but I can think of some hacks
+>>>>> that would limit the negative impact: a given translation's
+>>>>> status (currently = percent translated) could be displayed next
+>>>>> to the link that leads to it; a color code could as well be used
+>>>>> ("just" a matter of adding a CSS id or class to the links,
+>>>>> depending on this variable). As there is already work to be done
+>>>>> to have the links text generation more customizable through
+>>>>> plugins, I could do both at the same time if we consider this
+>>>>> matter to be important enough. --[[intrigeri]]
>> FWIW, I'm tracking your po branch in ikiwiki master git in the po
>> branch. One thing I'd like to try in there is setting up a translated
variables; they seem safe to me, but someone more expert than me
will need to check. Joey?
+ > Freaky code, but seems ok due to use of `quotementa`.
+
##### Text::WrapI18N
`Text::WrapI18N` can cause DoS (see the
> familiar with. I can learn and do it, in case no Perl wizard
> volunteers to provide the po4a patch. [[--intrigeri]]
+>> That doesn't really need to be in a BEGIN. This patch moves it to
+>> `import`, and makes this disable wrap18n:
+>> `use Locale::Po4a::Common q{nowrapi18n}` --[[Joey]]
+
+<pre>
+--- /usr/share/perl5/Locale/Po4a/Common.pm 2008-07-21 14:54:52.000000000 -0400
++++ Common.pm 2008-11-11 18:27:34.000000000 -0500
+@@ -30,8 +30,16 @@
+ use strict;
+ use warnings;
+
+-BEGIN {
+- if (eval { require Text::WrapI18N }) {
++sub import {
++ my $class=shift;
++ my $wrapi18n=1;
++ if ($_[0] eq 'nowrapi18n') {
++ shift;
++ $wrapi18n=0;
++ }
++ $class->export_to_level(1, $class, @_);
++
++ if ($wrapi18n && eval { require Text::WrapI18N }) {
+
+ # Don't bother determining the wrap column if we cannot wrap.
+ my $col=$ENV{COLUMNS};
+</pre>
+
##### Term::ReadKey
`Term::ReadKey` is not a hard dependency in our case, *i.e.* po4a
Perl seems to exit cleanly, and an incomplete PO file is written on
disk. I not sure whether if this is a bug in Perl or in `Po.pm`.
+> It's fairly standard perl behavior when fed malformed utf-8. As long as it doesn't
+> crash ikiwiki, it's probably acceptable. Ikiwiki can do some similar things itself when fed malformed utf-8 (doesn't crash tho) --[[Joey]]
+
#### po4a-translate
`po4a-translate` uses more or less the same po4a features as our
--- /dev/null
+Problem: Suppose a server has 256 mb ram. Each ikiwiki process needs about
+15 mb, before it's loaded the index. (And maybe 25 after, but only one such
+process runs at any time). That allows for about 16 ikiwiki processes to
+run concurrently on a server, before it starts to swap. Of course, anything
+else that runs on the server and eats memory will affect this.
+
+One could just set `MaxClients 16` in the apache config, but then it's also
+limited to 16 clients serving static pages, which is silly. Also, 16 is
+optimistic -- 8 might be a saner choice. And then, what if something on the
+server decides to eat a lot of memory? Ikiwiki can again overflow memory
+and thrash.
+
+It occurred to me that the ikiwiki cgi wrapper could instead do locking of
+its own (say of `.ikiwiki/cgilock`). The wrapper only needs a few kb to
+run, and it starts *fast*. So hundreds could be running waiting for a lock
+with no ill effects. Crank `MaxClients` up to 256? No problem..
+
+And there's no real reason to allow more than one ikiwiki cgi to run at a
+time. Since almost all uses of the CGI lock the index, only one can really
+be doing anything at a time. --[[Joey]]
+
+[[done]]
[[!inline archive="yes" sort="mtime" atom="yes" pages="
todo/allow_wiki_syntax_in_commit_messages*
todo/shortcut_with_different_link_text*
-todo/structured_page_data* "]]
+todo/structured_page_data*
+tips/convert_mediawiki_to_ikiwiki*
+"]]
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2008-11-07 12:23-0500\n"
+"POT-Creation-Date: 2008-11-11 15:36-0500\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
#. translators: The first parameter is a filename, and the second is
#. translators: a (probably not translated) error message.
-#: ../IkiWiki/Wrapper.pm:79
+#: ../IkiWiki/Wrapper.pm:93
#, perl-format
msgid "failed to write %s: %s"
msgstr ""
#. translators: The parameter is a C filename.
-#: ../IkiWiki/Wrapper.pm:135
+#: ../IkiWiki/Wrapper.pm:150
#, perl-format
msgid "failed to compile %s"
msgstr ""
#. translators: The parameter is a filename.
-#: ../IkiWiki/Wrapper.pm:155
+#: ../IkiWiki/Wrapper.pm:170
#, perl-format
msgid "successfully generated %s"
msgstr ""
msgid "preprocessing loop detected on %s at depth %i"
msgstr ""
-#: ../IkiWiki.pm:1685
+#: ../IkiWiki.pm:1672
msgid "yes"
msgstr ""
sipb-www / ikiwiki.git / commitdiff
