DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; q=dns; s=default; b=Sa
	ME1kd4j5keToWRgbWekMGskfjAyZqJ0be8sBL3DdvHbhQc0amYj+tqiPnPByeZCz
	wDwNntWM3amsJ14YSr2/lhmFULDYNzriYYDoSL8UCeIQ0Nfhf+R/CJMEYQiWkEmV
	AM9cffCV+N4BMLrui3dC1FHpxQmKx9C5TfkW5zSqY=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
MIME-Version: 1.0
In-Reply-To: <20151112122809.GB1774@calimero.vinschen.de>
References: <CACnvoQfd04snMS5OHu_WuqH+csXBWvXwUCutip9xZb6Hvi9ueg@mail.gmail.com>	<20151112122809.GB1774@calimero.vinschen.de>
Date: Fri, 13 Nov 2015 13:25:32 -0500
Message-ID: <CACnvoQcwa_tOkPMzoQ7Tjgxoip2U=FE78eDFrPb0KjBfd=tDVg@mail.gmail.com>
Subject: Re: 2.3.0: possible Cygwin flock bug (Windows 10 x86_64)
From: Mario Roy <marioeroy@gmail.com>
To: cygwin@cygwin.com
Content-Type: text/plain; charset=UTF-8

Hello Corinna,

I am writing to confirm that file locking, with MCE 1.608, utilizing
the development snapshot 2015-11-12 x86_64 is passing 100%. I ran
through other test cases including mixing threads and child processes.

Currently, MCE 1.608 does not allow one to mix threads and child
processes under Cygwin. I commented out the check in
MCE-1.608/lib/MCE.pm  (lines 424 - 435).

The following (mixing threads and child processes) now runs on Cygwin
using flock. Hurray !!!

use threads;
use threads::shared;
use MCE;

sub func {
   my ($mce) = @_;
   $mce->say($mce->wid);
}

my $mce = MCE->new(
 mutex_type => 'channel',
 user_tasks =>[{
    use_threads => 0,
    max_workers => 8,
    user_func   => \&func,
 },{
    use_threads => 0,
    max_workers => 8,
    user_func   => \&func,
 },{
    use_threads => 1,
    max_workers => 8,
    user_func   => \&func,
 },{
    use_threads => 0,
    max_workers => 8,
    user_func   => \&func,
 },{
    use_threads => 1,
    max_workers => 8,
    user_func   => \&func,
 }]
)->run;


The decision with channel locking for the upcoming MCE 1.7 release is
for another reason. In Perl, each worker must obtain the file lock
handle including threads. There are ulimit restrictions for number of
open file handles. With channel locking, workers are not having to
re-open any handles. Thus allowing the process to run with more
threads.

Recently, I simplified MCE/Mutex.pm to do channel locking only. Not to
worry, I may have MCE::Mutex support both channel and file locking.
Thus, will do the following for the upcoming MCE 1.700.

MCE-1.700/lib/MCE/Mutex.pm
MCE-1.700/lib/MCE/Mutex/Channel.pm
MCE-1.700/lib/MCE/Mutex/Flock.pm

Then, one may specify the type desired.

use MCE::Mutex;

my $m1 = MCE::Mutex->new( type => 'channel' );    # default if type is
not specified
my $m2 = MCE::Mutex->new( type => 'flock' );

Channel locking supports lock and unlock only.

$m1->lock;         # similarly to LOCK_EX
$m1->unlock;     # similarly to LOCK_UN

Will add the shared method for LOCK_SH in MCE/Mutex/Flock.pm

$m2->lock;
$m2->unlock;
$m2->shared;

MCE 1.700 in Github runs well with channel locking across the board.
However, being able to obtain a shared lock (possible with file
locking) at the application level is nice. Seeing the above example
work makes me confident in bringing back file locking and know that it
will work across platforms including Cygwin.

Thank you for fixing flock in Cygwin.dll.

Regards,
Mario

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple