StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
2987762
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
3
CommunityOwnedDate
CreationDate
2010-06-07T07:34:11.647
FavoriteCount
0
LastActivityDate
2010-06-07T16:33:52.693
LastEditDate
2010-06-07T16:33:52.693
LastEditorUserId
13164
OwnerUserId
13164
ParentId
2987712
PostTypeId
2
Score
6
ViewCount
0
LastEditorDisplayName
text
Body
<a href="http://search.cpan.org/perldoc?Time::HiRes" rel="nofollow noreferrer">Time::HiRes</a> comes with perl. Furthermore, your application sounds like it could benefit from <a href="http://search.cpan.org/perldoc?Linux::Inotify" rel="nofollow noreferrer">Linux::Inotify</a> (note the Linux:: in front). When setting the timer for a file that you want to remove after a certain time of inactivity, remember the last access. In an inotify event hook, update this time to the current time. Then, you can periodically check whether the file's lifetime expired without doing a stat on all of the files you track. On expiration, you could add a final check just to make sure nothing went wrong, of course. If you have huge numbers of files in flight, you may want to keep the list of files sorted by expiration time. That makes the periodic check for expiration trivial. Update: I just did a little experimentation with Linux::Inotify. Things aren't as easy with that approach as I thought. First, here's the partially working code that I didn't have time to finish. <pre><code>#!/usr/bin/env perl use strict; use warnings; use List::Util qw/min max/; use Time::HiRes qw/time sleep/; use Data::Dumper; use Linux::Inotify; # [s], but handles subsecond granularity, too use constant CLEANUP_INTERVAL => 1.; use constant FILE_ACCESS_TIMEOUT => 5.; # for fast and readable struct access use constant FILENAME => 0; use constant ACCESSTIME => 1; use constant WATCHER => 2; my $notifier = Linux::Inotify->new; my @tracked_files = populate_tracked_files(\@ARGV, $notifier); warn Dumper \@tracked_files; while (1) { # update the tracked files according to inotify events my @events = $notifier->read; my %files_seen_this_round; foreach my $event (@events) { $event->print(); my $ev_filename = $event->{name}; # part of the API, apparently # we mave have multiple events per file. next if $files_seen_this_round{$ev_filename}++; # find and update the right tracked file # TODO: this could be optimized to O(1) with a hash at # the cost of more bookkeeping foreach my $tfile (@tracked_files) { if ($tfile->[FILENAME] eq $ev_filename) { my $atime = $^T + 60*60*24 * -A $ev_filename; # update access time $tfile->[ACCESSTIME] = $atime; # a partial bubble sort would be hugely more efficient here! # => O(n) from O(n*log(n)) @tracked_files = sort {$a->[ACCESSTIME] <=> $b->[ACCESSTIME]} @tracked_files; last; } } # end foreach tracked file } # end foreach event cleanup_files(\@tracked_files); sleep(CLEANUP_INTERVAL); last if not @tracked_files; } # end while(1) $notifier->close; sub cleanup_files { my $files = shift; my $now = time(); for (my $fileno = 0; $fileno < $#{$files}; ++$fileno) { my $file = $files->[$fileno]; if ($now - $file->[ACCESSTIME] > FILE_ACCESS_TIMEOUT) { warn "File '" . $file->[FILENAME] . "' timed out"; # remove this file from the watch list # (and delete in your scenario) $file->[WATCHER]->remove; splice @$files, $fileno, 1; $fileno--; } } } sub populate_tracked_files { my $files = shift; my $notifier = shift; my @tracked_files; foreach my $file (@$files) { die "Not a file: '$file'" if not -f $file; my $watch = $notifier->add_watch($file, Linux::Inotify::ALL_EVENTS); push @tracked_files, [$file, $^T + 60*60*24*-A $file, $watch]; } @tracked_files = sort {$a->[ACCESSTIME] <=> $b->[ACCESSTIME]} @tracked_files; return @tracked_files; } </code></pre> There's still some bug in the time-checking logic. But the main problem is that <code>$notifier->read()</code> will block until a new event. Whereas we really just want to see whether there's a new event and then proceed to cleanup. This would have to be added to Linux::Inotify as a non-blocking read of the file descriptor. Anybody can take over maintenance of the module since <a href="https://rt.cpan.org/Public/Bug/Display.html?id=16581" rel="nofollow noreferrer">the author is no longer interested</a>.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POAre there any good timer implementations in Perl?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. UStsee
UserOwnerUserId
1. UStsee
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POAre there any good timer implementations in Perl?
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.