correction.
doesnt seem to work on the linux box. ftpd seems to unlink the existing file.
i cant see how this producer/consumer problem can be solved without getting the 
producer to co-operate.



the problem here is that the ftp daemon writes to the file. unless he hacks
the code there is no way he can make the ftpd honour whatever locking protocol 
he chooses. EXCEPT for mandatory locking. this is enabled for a file by setting
the set GID bit, and clearing the group exec bit.
chmod 2640 would set it. now the big question here is will using the perl flock
enable mandatory locking ???. AFAIK linux supports mandatory locking
/kk

On Tue, Jul 03, 2001 at 12:00:08PM +0200, Aaron Craig wrote:
> What about a simple text file (that could act as a cheap PID) which is 
> created by the first process that opens the file, and deleted by that 
> process when it's done.  Any other process that wants to access the same 
> file sleep()s until the text file gets deleted.  Hacky, maybe, but simple.
> 
> At 10:22 03.07.2001 +0200, you wrote:
> >  Hy all!
> >
> >I'am working on a webcam application and I enconter a problem. I have a
> >Camera, a video server and a Web/FTP server (Redhat 7.0, Apache
> >1.3.12-25, Wu-ftpd 2.6.1-6). My video server send 1 picture/s to the ftp
> >
> >server and the Web server pushes the pictures to the web client (Ie &
> >Netscape) by a cgi script. My problem is a concurrent file access
> >beetween the cgi script, which read the pictures file (1 per second) and
> >
> >the ftp server which write the picture file. The result of the error is
> >that the pictures appear truncated to the web client. Furthermore, when
> >the number of web client increases, the error increases too. I tried to
> >force simultaneous access to the file by using the perl function sysopen
> >
> >with the parameter O_NONBLOCK, but my pictures appear mixed. I use a
> >ramdisk to store the pictures which speeding the application but which
> >not solve the problem.
> >Now, I would like to synchronize the cgi file read access in order to
> >block the script picture reading while the file is being writing. How to
> >
> >do that ? If you have any other idea, I will be enjoyed ..
> >
> >Thank you for your future help..
> >
> >I joined the cgi script :
> >
> >#!/usr/bin/perl
> >#
> >#
> >
> >use Fcntl;
> >require 'stat.pl';
> >
> >#########################################################
> ># Path to where the image file is stored
> >$DIR = "/cam/";
> >#Filename the image is stored as
> >$fileName = "image.jpg";
> >#Maximum of images/s sent
> >$freq = 1;
> >#Max number of images to send on a connection
> >$maxImages = 900;
> >#Max number of seconds until update is considered stopped
> >#(ie the camera is no longer updating the image)
> >$maxNoUpdate = 30;
> >#########################################################
> >
> >$con_type = "jpeg";
> >
> ># Unbuffer the output so it streams through faster and better.
> >  $| = 1;
> >
> ># No input record separator when reading from file via <>.
> >undef $/;
> >
> ># Print HTTP headers...
> >
> >print "Content-type: multipart/x-mixed-replace;
> >boundary=--myboundary\n\n";
> >print "--myboundary\n";
> >
> >$rounds=0;
> >
> >while ($rounds < $maxImages)
> >{
> >   #$rounds =   $rounds +1;
> >   $basefile = $DIR . $fileName;
> >
> >   @fstat = stat($basefile);
> >
> >   # If the same image time stamp is on the image file for more then
> >   # X seconds then I presume that the image is no longer updated and
> >will
> >   # End the connection
> >
> >   if ($fstat[$ST_MTIME] ne $oldimagetime)
> >   {
> >       $sameCount = 0;
> >       $oldimagetime = $fstat[$ST_MTIME];
> >   }
> >
> >   #We may send the same image multiple times but there is a strict limit
> >
> >   if ($sameCount > ($maxNoUpdate * $freq))
> >   {
> >     die;
> >   }
> >
> >   $sameCount = $sameCount +1;
> >
> >   print "Content-type: image/$con_type\n\n";
> >
> >   open(PIC,"$basefile");
> >   print STDOUT <PIC>;
> >   close(PIC);
> >
> >   print "\n\n--myboundary\n";
> >
> >sleep($freq);
> >}
> >
> >
> >----- Gaël Jeanniard du Dot -----
> 
> Aaron Craig
> Programming
> iSoftitler.com

Reply via email to