simple pointer operations (newbe)

[Uri Guttman]

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

 

[Tassilo v. Parseval]

Also sprach Uri Guttman:

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

 

[Tassilo v. Parseval]

Also sprach Abigail:

Tassilo v. Parseval ([email protected]) wrote on
MMMMDLXIV September MCMXCIII in <URL:
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

 

[robic0]

Uri Guttman ([email protected]) wrote on MMMMDLXV September MCMXCIII in
<URL:``
`` 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