Skip Menu |

This queue is for tickets about the Mail-IMAPClient CPAN distribution.

Report information
The Basics
Id: 43413
Status: resolved
Priority: 0/
Queue: Mail-IMAPClient

People
Owner: Nobody in particular
Requestors: phil [...] perkpartners.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: remove apparent excessive use of fcntl calls in _read_line()
Date: Wed, 18 Feb 2009 17:26:04 -0500
To: bug-Mail-IMAPClient [...] rt.cpan.org
From: Phil Lobbes <phil [...] perkpartners.com>
Mail::IMAPClient 3.x (and 2.x) seem to call fcntl via Fast_io() while looping in _read_line() for what seems like no good reason (at least to me). Perhaps this was some hack/workaround for some probably long gone bug where Fast_io wasn't called when a caller supplied their own $socket object. Regardless, I think it is time to clean it up unless we can document some good reason for keeping it around. Below is a patch against Mail::IMAPClient 3.14. Phil $ diff -u IMAPClient.pm.ORIG IMAPClient.pm --- IMAPClient.pm.ORIG 2009-02-16 08:15:52.000000000 -0500 +++ IMAPClient.pm 2009-02-18 15:14:00.000000000 -0500 @@ -1314,7 +1314,6 @@ my $index = $self->_next_index; my $timeout = $self->Timeout; my $readlen = $self->{Buffer} || 4096; - my $fast_io = $self->Fast_io; until(@$oBuffer # there's stuff in output buffer: && $oBuffer->[-1][TYPE] eq 'OUTPUT' # that thing is an output line: @@ -1399,9 +1398,6 @@ { CORE::select(undef, undef, undef, 0.001); } - fcntl($socket, F_SETFL, $self->{_fcntl}) #???need??? - if $fast_io && defined $self->{_fcntl}; - my $ret = $self->_sysread($socket, \$litstring , $expected_size - length $litstring, length $litstring); @@ -1439,7 +1435,6 @@ . "invalid callback; must be a filehandle or CODE"); } - $self->Fast_io($fast_io) if $fast_io; # ??? push @$oBuffer, [$index++, 'LITERAL', $litstring]; } }
I fully agree with you. I was wondered about that piece of code as well, when I rewrote 2.* into 3.*, but did not want to break applications by removing apparent undocumented work-arounds. At least, now I can assign this removal to you, and blame you if someone complains ;-)