And well it doesnt work

That's not exactly an elaborate error description. Does your computer blow up when you run it? or your kitten dies? Or do you maybe just get an error message? If yes, what is it?

Well see that's it..
My kittens die.. heh

But indeed, I made a bit of a odd end that that error description. Well I wrote to scripts.The first one, and one that reads the file with mmap.

The Reader works, but that piece of code should write to the mmapped file. But it doesn't even do that...

The Writer doesn't do a thing at all.

I hope I supplied enough information now.
Thanks.

Not yet.

• Do you get an error message? If so, quote it exactly.
• Is the mmapped file updated in any manner? If so, state precisely what happens
• Does the script appear to execute and terminate? That may be part of the "enough information" we need to be helpful

Thanx for above Re^4, RobinV. This contained the missing info & confirmed the missing reader to be my suspected kitten, ahem - cat :). Btw. did you notice that your indenting didn't quite survive pasting?

Observation: It looks to me like $mmap isn't synced to file (or maybe even to the mmapped memory?) if the length changed, even if the new value _remains_ usable within the script. Modify your writer similar to the scrap below to make it work, but choose something more sensible than my substring mess.

# WORKS -- but it's suddenly quite slow due to synchronous sync :)
for(my $i=0;$i<105;++$i) { 
   substr($mmap,0,2) = substr($i . (" "x20) ,0,2); 
   sync($mmap,1); 
}
[download]

Maybe worth a check: There are more mmap modules on CPAN besides File::Map (Cache::FastMmap, Sys::Mmap + ::Simple, IPC::Mmap) some of which may turn out to be less rigid in assignments, maybe allowing implied remapping, padding or substring-insertion for shorter assignments.

I´m the author of File::Map. Due to circumstances I can't test or fix this right now, that will have to wait until next week.

This definitely is a bug, I´ll fix it as soon as I´m back home. Data loss as is observed here is not acceptable. Something seems to go wrong in the detection of direct assignment, it should have given a warning and then fix things up.

As for your second question: all other memory mapping modules either have the same issue of requiring substr() assignment to work properly, or use ties which cause the file to be copied completely on each read or write. The latter clearly isn't any better than the former IMSNHO.

Thanx for checking in, Leon.

It's rather as if something detects the assignment of wrong size and silently refuses. So from outside, bug #1 is either in refusing EXOR in being silent about refusing.

What kind of behaviour do you intend to provide on wrong-sized assignments (too large, too short, undef <=> replace & pad, overwrite beginning, resize mapping)? I don't remember anything in the module docs about what to expect, IIRC (buglet #2, either mine or your's :) ).

cu & thanx,
Peter

Thanks for the reply

Btw. did you notice that your indenting didn't quite survive pasting?

No I didnt..

I checked.. and well I do use sync($mmap,1);

Maybe worth a check: There are more mmap modules on CPAN besides File::Map

Well I had a look about, I found one thats good. However coming from a C world I thought of mmap ;) and D-Bus but DBus doesnt have documentation in perl.

My code works! ^^ Thanks

@Robin: The "indenting not surviving paste" refers to the leading whitespace in this code scrap

> 010:  map_file $mmap, $file, '+<';
> 011:   if (!defined($mmap)) { print "ERROR!!\n"; }
> 012:         for(my $i=0;$i<10000;++$i) { $mmap = $i; sync($mmap,1);
+ }
> 013:  unmap ($mmap);
[download]

all the statements are at the same level, but your indent above implied differently

map_file $mmap, $file, '+<';
if (!defined($mmap)) { print "ERROR!!\n";}
for(my $i=0;$i<10000;++$i) { 
   $mmap = $i; 
   sync($mmap,1);
}
unmap ($mmap);
[download]

cu,
Peter (wondering how he mismanaged his browser to get a duplicate node, but then using it to add the note on indenting here instead of asking for a reap).

DBUS? Then your question was more a XY question :).

While I can see shared memory to DBUS, my take of mmap is more about efficiency and accessing files other than with print&sysread. You might wish to post a separate question about DBUS.

CPAN offers at least one module for this: Net::DBus.

What I can offer on DBUS is a quick hack I did a while ago: check if I can see & send dbus events and somehow use them with waitcond - a rather primitive dbus example. Note that all I needed was the ability to grep and tail dbus, and thus a bit of glue, shell and an existing dbus monitoring tool was enough to conclude that experiment & obtain a useful but missing DBUS debug tool.

It seems I've got the bug squashed. I'll upload the fixed version to CPAN (0.18) ASAP.

Thanks for the bug report