Sorry :) but your script seems not doing what you explained above.
I have the impression that your problem is not related to a concurrency problem.
Could you send a more detailed code, please?
José.
Anyway, here some reads from Perl Cookbook :
16.11. Making a Process Look Like a File with Named Pipes
Problem
You want a process to intercept all access to a file. For instance, you want to make
your ~/.plan file a program that returns a random quote.
Solution
Use named pipes. First create one, probably from your shell:
% mkfifo /path/to/named.pipe
Here's a reader for it:
open(FIFO, "< /path/to/named.pipe") or die $!;
while (<FIFO>) {
print "Got: $_";
}
close(FIFO);
Here's a writer for it:
open(FIFO, "> /path/to/named.pipe") or die $!;
print FIFO "Smoke this.\n";
close(FIFO);
Discussion
A named pipe, or FIFO as they are also known, is a special file that acts as a buffer
to connect processes on the same machine. Ordinary pipes also allow processes to
communicate, but those processes must have inherited the filehandles from their
parents. To use a named pipe, a process need know only the named pipe's filename. In
most cases, processes don't even need to be aware that they're reading from a FIFO.
Named pipes can be read from and written to just as though they were ordinary files
(unlike Unix-domain sockets as discussed in Chapter 17, Sockets). Data written into
the FIFO is buffered up by the operating system, then read back in the order it was
written in. Because a FIFO acts as a buffer to connect processes, opening one for
reading will block until another process opens it for writing, and vice versa. If you
open for read and write using the +< mode to open, you won't block (on most systems)
because your process could be both reader and writer.
Let's examine how to use a named pipe so people will get a different file each time
they finger you. To create a named pipe, use mkfifo or mknod to create a named pipe
called .plan in your home directory:
% mkfifo ~/.plan # isn't this everywhere yet?
% mknod ~/.plan p # in case you don't have mkfifo
On some systems, you must use mknod (8). The location and names of these programs
aren't uniform or necessarily obvious, so consult your system documentation to find
out where these programs are.
The next step is to create a program to feed data to the programs that read from your
~/.plan file. We'll just print the date and time, as shown in Example 16.9.
Example 16.9: dateplan
#!/usr/bin/perl -w
# dateplan - place current date and time in .plan file
while (1) {
open(FIFO, "> $ENV{HOME}/.plan")
or die "Couldn't open $ENV{HOME}/.plan for writing: $!\n";
print FIFO "The current time is ", scalar(localtime), "\n";
close FIFO;
sleep 1;
}
Unfortunately, this won't always work, because some finger programs and their
attendant daemons check the size of the .plan file before trying to read it. Because
named pipes appear as special files of zero size on the filesystem, such clients and
servers will not try to open or read from our named pipe, and the trick will fail.
In our .plan example, the writer was a daemon. It's not uncommon for readers to be
daemons as well. Take, for instance, the use of a named pipe to centralize logging
from many processes. The log server reads log messages from the named pipe and can
send them to a database or file. Clients write their messages to the named pipe. This
removes the distribution logic from the clients, making changes to message
distribution easy to implement.
Example 16.10 is a simple program to read two-line messages where the first line is
the name of the service and the second line is the message being logged. All messages
from httpd are ignored, while all messages from login are saved to /var/log/login.
Example 16.10: fifolog
#!/usr/bin/perl -w
# fifolog - read and record log msgs from fifo
use IO::File;
$SIG{ALRM} = sub { close(FIFO) }; # move on to the next queued process
while (1) {
alarm(0); # turn off alarm for blocking open
open(FIFO, "< /tmp/log") or die "Can't open /tmp/log : $!\n";
alarm(1); # you have 1 second to log
$service = <FIFO>;
next unless defined $service; # interrupted or nothing logged
chomp $service;
$message = <FIFO>;
next unless defined $message; # interrupted or nothing logged
chomp $message;
alarm(0); # turn off alarms for message processing
if ($service eq "http") {
# ignoring
} elsif ($service eq "login") {
# log to /var/log/login
if ( open(LOG, ">> /tmp/login") ) {
print LOG scalar(localtime), " $service $message\n";
close(LOG);
} else {
warn "Couldn't log $service $message to /var/log/login : $!\n";
}
}
}
This program is more complicated than the .plan program for several reasons. First and
foremost, we don't want our logging server to block would-be writers for long. It's
easy to imagine a situation where an attacker or misbehaving writer opens the named
pipe for writing, but doesn't send a complete message. To prevent this, we use alarm
and SIGALRM to signal us if we get stuck reading.
Only two exceptional conditions can happen when using named pipes: a writer can have
its reader disappear, or vice versa. If a process is reading from a named pipe and the
writer closes its end, the reading process will get an end of file (<> returns undef).
If the reader closes the connection, though, the writer will get a SIGPIPE when it
next tries to write there. If you disregard broken pipe signals with $SIG{PIPE} =
'IGNORE', your print will return a false value and $! will be set to EPIPE:
use POSIX qw(:errno_h);
$SIG{PIPE} = 'IGNORE';
# ...
$status = print FIFO "Are you there?\n";
if (!$status && $! == EPIPE) {
warn "My reader has forsaken me!\n";
next;
}
You may be asking "If I have 100 processes all trying simultaneously to write to this
server, how can I be sure that I'll get 100 separate entries and not a jumbled
mishmash with characters or lines from different processes?" That's a good question.
The POSIX standard says that writes of less than PIPE_BUF bytes in size will be
delivered atomically, i.e. not jumbled. You can get the PIPE_BUF constant from POSIX:
use POSIX;
print _POSIX_PIPE_BUF, "\n";
Fortunately, the POSIX standard also requires PIPE_BUF to be at least 512 bytes. This
means that all we have to do is ensure that our clients don't try to log more than 512
bytes at a time.
What if you want to log more than 512 bytes at a time? Then you split each large
message into several smaller (fewer than 512 bytes) messages, preface each with the
unique client identifier (process ID, say) and have the server reassemble them. This
is similar to the processing involved in TCP/IP message fragmentation and reassembly.
Because a single named pipe doesn't allow bidirectional access between writer and
reader, authentication and similar ways of preventing forged messages are hard to do
(if not impossible). Rather than struggle to force such things on top of a model that
doesn't accommodate them, you are better off using the filesystem's access control to
restrict access to the file through the owner and group permissions on the named pipe.
See Also
mkfifo (8) or mknod (8) (if you have them); Recipe 17.6
> -----Original Message-----
> From: Enric Roca [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 27, 2003 12:21 PM
> To: Beginners Perl
> Subject: Concurrency problem
>
>
> Hello,
>
> We are using Apache 1.3.26, Perl 5.5.3 and perl-cgi
> scripting to communicate to applications with XML. App1 calls
> the cgi script that is placed in the other machine. The
> script reads the XML message and pass it to pipe1. This
> message is processed by App2 and a response message is
> returned to pipe2 and sent to App1.
>
> The process works fine, but we have detected an issue when
> more that one XML message is sent at the same time. The first
> message that arrives is well processed but the second message is lost.
>
> Any ideas about what to do in the Perl script to avoid
> concurrency problems ?
>
> This is the script:
>
>
> #!/usr/local/bin/perl
> print "Content-type: text/xml\n";
> use CGI;
> read(STDIN, $cadena, $ENV{'CONTENT_LENGTH'});
>
> $cadena =~ tr/+/ /; # reeplace the + sign by spaces
>
> $request = "> /myfolder/mypipe/pipe1";
>
> unless (open(SYSREQUEST, $request))
> {
> die("Impossible to open the pipe $request\n");
> }
>
> print SYSREQUEST "$cadena\n";
>
> close(SYSREQUEST);
>
> $request2 = "/myfolder/mypipe/pipe2";
>
> unless (open(SYSREQUEST2, $request2))
> {
> die("Impossible to open the pipe $request2\n");
> }
>
> while ( <SYSREQUEST2> )
> {
> print "$_\n";
> }
> close(SYSREQUEST2);
>
>
> Thank you very much in advance,
>
> Enric
>
>
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
**** DISCLAIMER ****
"This e-mail and any attachment thereto may contain information which is confidential
and/or protected by intellectual property rights and are intended for the sole use of
the recipient(s) named above.
Any use of the information contained herein (including, but not limited to, total or
partial reproduction, communication or distribution in any form) by other persons than
the designated recipient(s) is prohibited.
If you have received this e-mail in error, please notify the sender either by
telephone or by e-mail and delete the material from any computer".
Thank you for your cooperation.
For further information about Proximus mobile phone services please see our website at
http://www.proximus.be or refer to any Proximus agent.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
