Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > simple pointer operations (newbe)

Reply
Thread Tools

simple pointer operations (newbe)

 
 
Uri Guttman
Guest
Posts: n/a
 
      03-01-2006
>>>>> "AS" == Anno Siegel <(E-Mail Removed)-berlin.de> writes:

AS> Uri Guttman <(E-Mail Removed)> wrote in comp.lang.perl.misc:

>> the sv (or whatever the internal thing the ref is) never get reallocated
>> as they are fixed sized. only the string/array/hash buffers get
>> reallocated as needed and they are pointed to by a member of the sv. so
>> the ref value will never change as long as the ref is valid (not garbage
>> collected).


AS> There is one exception: On thread (ithread) creation, everything is
AS> cloned and one of the branches wakes up with all refaddrs changed.

AS> That's why some implementations of inside-out classes aren't thread-safe.
AS> An object in a newly cloned thread will appear to have lost its data.
AS> The problem is fixable, at a price.

AS> As far as I'm concerned thread users get what they deserve and deserve
AS> what they get

as a strong advocate of event loops over threads i fully agree with that
sentiment.

uri

--
Uri Guttman ------ http://www.velocityreviews.com/forums/(E-Mail Removed) -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
 
Reply With Quote
 
 
 
 
Tassilo v. Parseval
Guest
Posts: n/a
 
      03-05-2006
Also sprach Uri Guttman:

>>>>>> "AS" == Anno Siegel <(E-Mail Removed)-berlin.de> writes:

>
> AS> Uri Guttman <(E-Mail Removed)> wrote in comp.lang.perl.misc:
>
> >> the sv (or whatever the internal thing the ref is) never get reallocated
> >> as they are fixed sized. only the string/array/hash buffers get
> >> reallocated as needed and they are pointed to by a member of the sv. so
> >> the ref value will never change as long as the ref is valid (not garbage
> >> collected).

>
> AS> There is one exception: On thread (ithread) creation, everything is
> AS> cloned and one of the branches wakes up with all refaddrs changed.
>
> AS> That's why some implementations of inside-out classes aren't thread-safe.
> AS> An object in a newly cloned thread will appear to have lost its data.
> AS> The problem is fixable, at a price.
>
> AS> As far as I'm concerned thread users get what they deserve and deserve
> AS> what they get
>
> as a strong advocate of event loops over threads i fully agree with that
> sentiment.


And as someone having done quite a bit with events myself, I have to
mention that they are two totally different things.

Although you can sometimes get away with events and avoid threads or
processes, you will still need some means of real concurrency. Whenever
an event handler may block or carry out a complex computation that takes
a while, you have to run it in a separate process or thread or otherwise
your event loop will block for the time the handler is running.

Well, I know that you know that. But for Event::Lib, I received quite a
few mails from people who were apparently under the misapprehension that
each event handler is triggered in its own process or thread. An
event-based application is still running sequentially so it will not
always spare one the pain to use fork() or threads.

Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854 220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($ m+=<=200);
 
Reply With Quote
 
 
 
 
Tassilo v. Parseval
Guest
Posts: n/a
 
      03-05-2006
Also sprach Abigail:

> Tassilo v. Parseval ((E-Mail Removed)) wrote on
> MMMMDLXIV September MCMXCIII in <URL:news:(E-Mail Removed)>:
>
> Yes, inside-out indeed seems to be Perl-centric. On the other hand, it's
> nothing that would have been invented by the Perl folks. They are a
> variation on the flyweight-pattern where an object is a very lightweight
> entity ($dummy in the above article) and it is used to look up the real
> data from some static container outside the caller's scope.
>
> Besides avoiding typos, they have some other advantages. One is that
> subclassing becomes easier and safer as the access to an object's
> innards happens exlusively through accessor methods.
>
> That's not quite right. The essence of avoiding name clashes doesn't
> lie in exclusive access through accessor methods, it lies in storing
> attributes in a structure that's bound to the class that uses the
> attributes, and not the object.
>
> Now usually this means you use a lexical hash, and you use one class
> per file, so accessors is the only feasible access. But it doesn't have
> to. If you do something like:
>
> package MyClass;
>
> our %attribute; # Instead of 'my %attribute'.
>
> ...
>
> you can access attributes defined in another class without accessor methods,
> and still enjoy all the benefits InsideOut objects give you. Using 'our'
> instead of 'my' maybe handy if you want to write a serialiser.
>
> Remember, inside-out objects aren't about enforcing encapsulation, it's
> all about preventing *accidental* globbering someone elses internals.


Ah, alright. I have to add that I've never used the inside-out pattern
yet (or at least not consciously) so my conception of it may be a little
foggy and inaccurate. Thanks for the explanation.

Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854 220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($ m+=<=200);
 
Reply With Quote
 
robic0
Guest
Posts: n/a
 
      03-09-2006
On 01 Mar 2006 19:41:35 GMT, Abigail <(E-Mail Removed)> wrote:

>Uri Guttman ((E-Mail Removed)) wrote on MMMMDLXV September MCMXCIII in
><URL:news(E-Mail Removed)>:
>`` >>>>> "R" == Ruud <(E-Mail Removed)> writes:
>``
>`` R> Uri Guttman schreef:
>`` >> the fact that perl uses the a
>`` >> real c address as part of the value (numeric or string) of references
>`` >> is total smart as it will guarantee the uniqueness of the ref value
>`` >> since the ram address is also unique.
>``
>`` R> Well, unique until the allocated block is moved. Unless the address is
>`` R> more like a handle. Or the block was allocated as fixed.
>``
>`` the sv (or whatever the internal thing the ref is) never get reallocated
>`` as they are fixed sized. only the string/array/hash buffers get
>`` reallocated as needed and they are pointed to by a member of the sv. so
>`` the ref value will never change as long as the ref is valid (not garbage
>`` collected).
>
>
>SV might get reallocated - or rather, copied, when you may not expect it,
>for instance when using threads.
>
>
> #!/opt/perl/5.8.8/bin/thr-perl-64 -l
>
> use threads;
> use strict;
> use warnings;
>
> my $ref = do {\my $var};
>
> print $ref;
>
> threads -> create (sub {print $ref}) -> join;
>
> __END__
> SCALAR(0x81a8390)
> SCALAR(0x828649c)
>
>
>Abigail


Where's the C constructs Abigail? Are you back to
Perl now?

SCALAR(0x81a8390)

Whats this a virtual address to a Perl malloc'ed
er, ahh... something you can change?

0x81a8390 does seem like an awfully big damn number
you know? What do you think 0x81a8391 is?

Oh yeah, its a void pointer (or typedef) to an array
of structures. By incrementing the pointer in Perl
you can get the contents of the next structure:

struct mine {
struct *mine;
int *asdf;
char sdf[25];
} MINE;

MINE *minehdr = malloc (1000 * sizeof(MINE));
// assign

yadayadayada
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Pointer to pointer or reference to pointer A C++ 7 07-05-2011 07:49 PM
Pointer to pointer Vs References to Pointer bansalvikrant@gmail.com C++ 4 07-02-2009 10:20 AM
passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer jimjim C Programming 16 03-27-2006 11:03 PM
stand-alone JMS, other JDBC operations, and transactions ( ActiveMQ + JOTM + JDBC operations ) Jesus M. Salvo Jr. Java 2 02-11-2006 06:33 PM
Pointer-to-pointer-to-pointer question masood.iqbal@lycos.com C Programming 10 02-04-2005 02:57 AM



Advertisments