Re: Bytecode metadata
On 01/26/2003 2:18 PM, Sean O'Rourke wrote: Maybe a config option? The app I'm thinking of was pathological, in that it mapped in thousands of 20-byte files. Now that I think about it, unless someone implements something very strangely (or has absolutely enormous numbers of threads) this shouldn't be an issue. Might I suggest that we make sure we can deal sanely with either mmaping or reading PBC files, and then worry about this later, like when somebody actualy finds it being a problem in real use? -=- James Mastros
Re: Bytecode metadata
On 01/25/2003 4:26 AM, Leopold Toetsch wrote: Nicholas Clark wrote: Also some way of storing a cryptographic signature in the file, so that you could compile a parrot that automatically refuses to load code that isn't signed by you. The palladium parrot :) Just because it's possible to use a technology for evil doesn't mean you shouldn't create it. I think it would be quite useful to define a standard for signed PBC. It doesn't need to be complex; just define a new packfile section, SIGNATURE, that is defined to be a cryptographic signature of all sections previous to it in the file. (We'd have to exclude certian parts of the header, or otherwise work around chicken-and-egg problems with the signed header changing in the act of attaching the signature, but those are long-since-solved problems.) In purticlar, it would be nice to be able to trust code written by myself and people I personaly trust, run CPAN code in checked mode, run code submited by users without access to create IO PMCs, and not run Micorosoft code at all. A code signing standard would enable that. It's defining a trust model that doesn't let the user know what's actualy going on that we have to be wary of. (Even authenticating the host is potentialy useful... though I can't think of a good use.) -=- James Mastros
Re: Bytecode metadata
On Sat, 25 Jan 2003, Leopold Toetsch wrote: > Is one PBC file a small thing? Or in other words, should we have a low > limit where we start again to malloc and copy PBC files? > Configure option? Commandline switch? Maybe a config option? The app I'm thinking of was pathological, in that it mapped in thousands of 20-byte files. Now that I think about it, unless someone implements something very strangely (or has absolutely enormous numbers of threads) this shouldn't be an issue. /s
Re: Bytecode metadata
On Sat, Jan 25, 2003 at 05:38:08PM -0800, Sean O'Rourke wrote: > The problem's actually _virtual_ memory use/fragmentation, not physical > memory or swap. Say you map in 10k small files -- that's 640M virtual > memory, just over a fourth of what's available. Now let's say you're also > using mmap() in your webserver to send large (10M) files quickly over the > network. The small files, if they're long-lived get scattered all over > VA-space, so there's a non-trivial chance that the OS won't be able to > find a 10MB chunk of free addresses at some point. Yeah, but in pratice, most, if not all the small files will mapped in at startup. It's no different than the situation at the moment on Solaris where XS modules require the .so object to be mmapped in. > Weird, I know, but that's why it stuck in my mind. You have to map quite > a few files to get this to happen, but it's a real possibility with a > 32-bit address space and a long-running process that does many small > mmap()s and some large ones. But we'll all be using 64-bit processors by the time parrot's released :-) -- This email is confidential, and now that you have read it you are legally obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have received this email in error, place it in its original wrapping and return for a full refund. By opening this email, you accept that Elvis lives.
Re: AUTOLOADED pre- and post- handler methods?
Dan Sugalski wrote in perl.perl6.internals :
>
> In Perl terms, assume we have a method PRE that gets called before
> any method in a class is called, and AUTOLOAD which is called if you
> call a method on a class and that method doesn't exist. Does AUTOLOAD
> have to get called to check for PRE if PRE doesn't exist in a class?
In Perl 5, AUTOLOAD is called for destructors :
$ perl -wle 'sub AUTOLOAD{print $AUTOLOAD};bless{}'
main::DESTROY
While I think this is annoying in most cases, I imagine this may be
useful. And adding an empty destructor to a class is not a huge effort.
The situation is similar for a PRE method. If it's not defined, there's
no error ; if it's not defined but if AUTOLOAD exists, AUTOLOADing is
tried. (I imagine that if AUTOLOAD gracefully refuses to create the PRE
method, no further attempt will be made.)
Re: Bytecode metadata
Sean O'Rourke wrote: How true. On Solaris, for example, mmap's are aligned on 64k boundaries, which leads to horrible virtual address space consumption when you map lots of small things. If we're mmap()ing things, we want to be sure they're fairly large. Is one PBC file a small thing? Or in other words, should we have a low limit where we start again to malloc and copy PBC files? Configure option? Commandline switch? /s leo
