Bug #60694 for CGI-Session: Serialized sessions are non-portable between architectures

Tue Aug 24 11:55:49 2010 KAPPA [...] cpan.org - Ticket created

CGI::Session uses Storable::freeze and thus its sessions are inherently non-portable between differently endian machines. We have a driver that does s/freeze/nfreeze/. It would be simpler and nicer to just have an option to use nfreeze (or even default to it, the overhead is neglible).

Tue Aug 24 11:56:07 2010 KAPPA [...] cpan.org - Status changed from 'new' to 'open'

Tue Aug 24 11:57:39 2010 KAPPA [...] cpan.org - Subject changed from (no value) to 'Serialized sessions are non-portable between architectures'

Tue Aug 24 11:58:37 2010 KAPPA [...] cpan.org - Cc HSW added

Tue Aug 24 12:04:11 2010 mark [...] summersault.com - Correspondence added

Subject:	Re: [rt.cpan.org #60694] support for nfreeze as an alternative to freeze
Date:	Tue, 24 Aug 2010 12:03:58 -0400
To:	bug-CGI-Session [...] rt.cpan.org
From:	Mark Stosberg <mark [...] summersault.com>

On Tue, 24 Aug 2010 11:55:50 -0400 "Alex Kapranoff via RT" <bug-CGI-Session@rt.cpan.org> wrote: Show quoted text

> Tue Aug 24 11:55:49 2010: Request 60694 was acted upon. > Transaction: Ticket created by KAPPA > Queue: CGI-Session > Subject: (No subject given) > Broken in: 2.2 > Severity: Important > Owner: Nobody > Requestors: KAPPA@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=60694 > > > > CGI::Session uses Storable::freeze and thus its sessions are inherently > non-portable between differently endian machines. > > We have a driver that does s/freeze/nfreeze/. It would be simpler and > nicer to just have an option to use nfreeze (or even default to it, the > overhead is neglible).

Will changing the default from freeze to nfreeze break anyones code who upgrades and has data that has been frozen with "freeze" instead of "nfreeze" ? Some automated tests that illustrate the safety of that would be helpful. A benchmark of freeze vs. nfreeze would also be helpful. If there is really little overhead and better compatibility, I like the idea of updating it as the default. Mark

Tue Aug 24 17:11:06 2010 KAPPA [...] cpan.org - Correspondence added

First, there's only one thaw(), so there won't be any problems with thawing nfrozen data versus frozen data. Second, I attach a simple benchmark script. On my boxes nfreeze() ends up being 5-10% slower. Thawing nfrozen data also is 5-10% slower. See for yourself. Втр Авг 24 12:04:11 2010, mark@summersault.com писал: Show quoted text

> On Tue, 24 Aug 2010 11:55:50 -0400 > "Alex Kapranoff via RT" <bug-CGI-Session@rt.cpan.org> wrote: >

> > Tue Aug 24 11:55:49 2010: Request 60694 was acted upon. > > Transaction: Ticket created by KAPPA > > Queue: CGI-Session > > Subject: (No subject given) > > Broken in: 2.2 > > Severity: Important > > Owner: Nobody > > Requestors: KAPPA@cpan.org > > Status: new > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=60694 > > > > > > > CGI::Session uses Storable::freeze and thus its sessions are

inherently Show quoted text

> > non-portable between differently endian machines. > > > > We have a driver that does s/freeze/nfreeze/. It would be simpler

and Show quoted text

> > nicer to just have an option to use nfreeze (or even default to it,

the Show quoted text

> > overhead is neglible).

> > Will changing the default from freeze to nfreeze break anyones code

who Show quoted text

> upgrades and has data that has been frozen with "freeze" instead of > "nfreeze" ? Some automated tests that illustrate the safety of that > would be helpful. > > A benchmark of freeze vs. nfreeze would also be helpful. If there is > really little overhead and better compatibility, I like the idea of > updating it as the default. > > Mark

Subject:

serialize.pl

#!/usr/bin/perl use strict; use warnings; use Storable; use Benchmark qw/timethese/; my $data = { id => "ds" x 40 }; timethese(300000, { freeze => sub { Storable::freeze($data) }, nfreeze => sub { Storable::nfreeze($data) }, });

Wed Aug 25 09:14:58 2010 mark [...] summersault.com - Correspondence added

Subject:	Re: [rt.cpan.org #60694] Serialized sessions are non-portable between architectures
Date:	Wed, 25 Aug 2010 09:14:49 -0400
To:	bug-CGI-Session [...] rt.cpan.org
From:	Mark Stosberg <mark [...] summersault.com>

On Tue, 24 Aug 2010 17:11:07 -0400 "Alex Kapranoff via RT" <bug-CGI-Session@rt.cpan.org> wrote: Show quoted text

> Queue: CGI-Session > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=60694 > > > First, there's only one thaw(), so there won't be any problems with > thawing nfrozen data versus frozen data. > > Second, I attach a simple benchmark script. On my boxes nfreeze() ends > up being 5-10% slower. > > Thawing nfrozen data also is 5-10% slower. See for yourself.

Great. Thanks for that research. It sounds like switching nfreeze is a reasonable choice then, given how fast computers are now. Mark

Wed Aug 25 10:01:27 2010 kapranoff [...] gmail.com - Correspondence added

CC:	KAPPA [...] cpan.org, HSW [...] cpan.org
Subject:	Re: [rt.cpan.org #60694] Serialized sessions are non-portable between architectures
Date:	Wed, 25 Aug 2010 18:00:58 +0400
To:	bug-CGI-Session [...] rt.cpan.org
From:	Alex Kapranoff <kapranoff [...] gmail.com>

Actually, I think that losing even 5% may hurt some people. I would vote for an option to sacrifice portability for extra bit of speed. -- Alex Kapranoff. On Wed, Aug 25, 2010 at 17:14, mark@summersault.com via RT < bug-CGI-Session@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=60694 > > > On Tue, 24 Aug 2010 17:11:07 -0400 > "Alex Kapranoff via RT" <bug-CGI-Session@rt.cpan.org> wrote: >

> > Queue: CGI-Session > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=60694 > > > > > First, there's only one thaw(), so there won't be any problems with > > thawing nfrozen data versus frozen data. > > > > Second, I attach a simple benchmark script. On my boxes nfreeze() ends > > up being 5-10% slower. > > > > Thawing nfrozen data also is 5-10% slower. See for yourself.

> > Great. Thanks for that research. It sounds like switching nfreeze is a > reasonable choice then, given how fast computers are now. > > Mark > >

Wed Aug 25 10:29:16 2010 KAPPA [...] cpan.org - Correspondence added

We rerun benchmarks and figured out that on most of the boxes the difference is even smaller than 5% (more like 1-3%). Срд Авг 25 10:01:27 2010, kapranoff@gmail.com писал: Show quoted text

> Actually, I think that losing even 5% may hurt some people. I would

vote for Show quoted text

> an option to sacrifice portability for extra bit of speed. >

Tue Oct 06 14:42:12 2015 KAPPA [...] cpan.org - Correspondence added

25 Ağu 2010 Çrş, 09:14:58 tarihinde, mark@summersault.com yazdı: Show quoted text

> On Tue, 24 Aug 2010 17:11:07 -0400 > "Alex Kapranoff via RT" <bug-CGI-Session@rt.cpan.org> wrote: >

> > Queue: CGI-Session > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=60694 > > > > > First, there's only one thaw(), so there won't be any problems with > > thawing nfrozen data versus frozen data. > > > > Second, I attach a simple benchmark script. On my boxes nfreeze() ends > > up being 5-10% slower. > > > > Thawing nfrozen data also is 5-10% slower. See for yourself.

> > Great. Thanks for that research. It sounds like switching nfreeze is a > reasonable choice then, given how fast computers are now. > > Mark

The suggestion is still relevant. I am attaching the simplest patch.

Subject:

patch-nfreeze

Download patch-nfreeze
application/octet-stream 281b

Message body not shown because it is not plain text.