| Win32::IPC - Base class for Win32 synchronization objects |
Win32::IPC - Base class for Win32 synchronization objects
This document describes version 1.11 of Win32::IPC, released November 15, 2014 as part of Win32-IPC version 1.11.
use Win32::Event 1.00 qw(wait_any);
#Create objects.
wait_any(@ListOfObjects, $timeout);
This module is loaded by the other Win32 synchronization modules. You shouldn't need to load it yourself. It supplies the wait functions to those modules.
The synchronization modules are the Win32::ChangeNotify manpage, the Win32::Event manpage, the Win32::Mutex manpage, & the Win32::Semaphore manpage.
In addition, you can use wait_any and wait_all with
the Win32::Console manpage and the Win32::Process manpage objects. (However, those
modules do not export the wait functions; you must load one of the
synchronization modules (or just Win32::IPC)).
Win32::IPC supplies one method to all synchronization objects.
wait([$timeout])$obj to become signalled. $timeout is the maximum time
to wait (in milliseconds). If $timeout is omitted or undef,
waits forever. If $timeout is 0, returns immediately.
Returns:
+1 The object is signalled
-1 The object is an abandoned mutex
0 Timed out
undef An error occurred (check C<$^E> for details)
@objects to become signalled.
$timeout is the maximum time to wait (in milliseconds). If
$timeout is omitted or undef, waits forever. If $timeout is
0, returns immediately.
The return value indicates which object ended the wait:
+N $object[N-1] is signalled
-N $object[N-1] is an abandoned mutex
0 Timed out
undef An error occurred (check C<$^E> for details)
If more than one object became signalled, the one with the lowest index is used.
wait_any, but it waits for all the @objects
to become signalled. The return value indicates the last object to
become signalled, and is negative if at least one of the @objects
is an abandoned mutex.
Win32::IPC still supports the ActiveWare syntax, but its use is deprecated.
$timeout argument
(or pass undef) instead.
INFINITE is only mildly deprecated. If you have a good use for it,
feel free to continue to use it. That is, $object->wait(INFINITE)
is pointless, but $object->wait($timeout) (where $timeout
may or may not equal INFINITE) may make sense.
WaitForMultipleObjects erases @objects!
Use wait_all or wait_any instead.
Wait($timeout)not $obj->wait($timeout).
The wait_any and wait_all functions support two kinds of
objects. Objects derived from Win32::IPC are expected to consist
of a reference to a scalar containing the Win32 HANDLE as an IV.
Other objects (for which UNIVERSAL::isa($object, "Win32::IPC") is
false), are expected to implement a get_Win32_IPC_HANDLE method.
When called in scalar context with no arguments, this method should
return a Win32 HANDLE (as an IV) suitable for passing to the Win32
WaitForMultipleObjects API function.
None.
Win32::IPC requires no configuration files or environment variables.
It runs under 32-bit or 64-bit Microsoft Windows, either natively or under Cygwin.
None.
Prior to version 1.06, the Win32 IPC modules treated undef values
differently. In version 1.06 and later, passing undef as the value
of an optional parameter is the same as omitting that parameter. In
previous versions, undef was interpreted as either the empty string
or 0 (along with a warning about ``Use of uninitialized value...'').
If your program uses signal handlers (installed using %SIG), and a
handled signal arrives while the program is in one of the IPC wait
functions (wait, wait_any, or wait_all), the signal handler
will not be executed until the wait ends. For instance, this means
you can't interrupt a wait with Control-C if you have installed a
$SIG{INT} handler.
The root cause of this is that Perl defers running the signal handler until the Perl interpreter is in a safe state. See Deferred Signals (Safe Signals) in the perlipc manpage. I don't know of any proper solution to this; if you do, please let me know.
One possible workaround is to use threads, and do the wait in a secondary thread while the main thread continues to handle signals. The main thread could signal the secondary thread using a the Win32::Event manpage object.
Another workaround is to use a relatively short timeout. You can retry the wait as needed. Each timeout gives any queued-up signal handlers a chance to run.
Christopher J. Madsen <perl AT cjmweb.net>
Please report any bugs or feature requests
to <bug-Win32-IPC AT rt.cpan.org>
or through the web interface at
http://rt.cpan.org/Public/Bug/Report.html.
You can follow or contribute to Win32-IPC's development at https://github.com/madsen/win32-ipc.
Loosely based on the original module by ActiveWare Internet Corp., http://www.ActiveState.com
Copyright 1998-2014 Christopher J. Madsen
Created: 3 Feb 1998 from the ActiveWare version (c) 1995 Microsoft Corporation. All rights reserved. Developed by ActiveWare Internet Corp., http://www.ActiveState.com
Other modifications (c) 1997 by Gurusamy Sarathy <gsar AT cpan.org>
This module is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.
BECAUSE THIS SOFTWARE IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE SOFTWARE, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE SOFTWARE ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH YOU. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR, OR CORRECTION.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE SOFTWARE AS PERMITTED BY THE ABOVE LICENSE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE SOFTWARE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE SOFTWARE TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
| Win32::IPC - Base class for Win32 synchronization objects |