On Thu, Jul 31, 2008 at 5:32 PM, ron minnich <[EMAIL PROTECTED]> wrote:
> here is a thought:
>
> the kernel does mmap for code/data. This is because we think of a file
> as a segment of data that somehow maps well to a segment of memory.
>
> You wouldn't execute code from a stream, now, would you?
> Does this also affect 9vx.Linux version.
it affects linux, but not the 0.12 binaries.
> I have been testing a few
> ports under it and it seems to crash in different places. I have not
> been able to isolate the type of code causes it so I did not report it
> on the list. It does seem to happe
here is a thought:
the kernel does mmap for code/data. This is because we think of a file
as a segment of data that somehow maps well to a segment of memory.
You wouldn't execute code from a stream, now, would you?
Well, this: http://www.ambric.com/
has hardware channels. And you can
call from
Does this also affect 9vx.Linux version. I have been testing a few
ports under it and it seems to crash in different places. I have not
been able to isolate the type of code causes it so I did not report it
on the list. It does seem to happen when I allocate a huge amount of
memory for a dense matr
On Thu, 31 Jul 2008 22:39:43 BST Charles Forsyth <[EMAIL PROTECTED]> wrote:
> > Does anyone have pointers to *nice* interfaces for doing this? I don't
> > care which OS, but I'd like to not have the implementation I'm
> > requesting suck because I missed some gotchas that someone else already h
On Thu, Jul 31, 2008 at 3:17 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
>> >> OK, am I just out of date or is there a real reason for linker
>> >> sets?This question just came up in linuxbios v3 and I am wondering if
>> >> I am a stubborn old coot (likely) or if there really is merit to my
>> >>
> >> OK, am I just out of date or is there a real reason for linker
> >> sets?This question just came up in linuxbios v3 and I am wondering if
> >> I am a stubborn old coot (likely) or if there really is merit to my
> >> dislike of linker sets.
> >
> > why can't both be true?
> >
>
> I suspect bot
>> Also, if you do create a Plan 9 partition and
>> then prep it to make subpartitions (you'd have
>> to use 9vx, copying the binaries from sources),
>> then p9p venti can handle those partition names
>> too: /dev/sda1:arenas assuming /dev/sda1 is a
>> Plan 9 fdisk partition containing a subpartiti
On Thu, Jul 31, 2008 at 3:04 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
>> OK, am I just out of date or is there a real reason for linker
>> sets?This question just came up in linuxbios v3 and I am wondering if
>> I am a stubborn old coot (likely) or if there really is merit to my
>> dislike of
> OK, am I just out of date or is there a real reason for linker
> sets?This question just came up in linuxbios v3 and I am wondering if
> I am a stubborn old coot (likely) or if there really is merit to my
> dislike of linker sets.
why can't both be true?
- erik
On Thu, Jul 31, 2008 at 3:03 PM, Charles Forsyth <[EMAIL PROTECTED]> wrote:
> speaking of higher levels of abstraction:
> given some scientific code i've seen (before this, nothing to do with the
> things
> running on Blue Gene), i'd observe that fixing some of the algorithms used
> (which
> is
For some time now, over 10 years anyway, the GNU world has been using
the linker to create initialized structs, viz:
static const struct cpu_driver driver __cpu_driver = {
.ops = &cpu_dev_ops,
.id_table = cpu_table,
};
(this from linuxbios)
The __cpu_driver is passed to the linker
you could change the subject line to continue this discussion
for other reasons, but for this particular work on plan 9,
it's not worth getting into a discussion of aspects of belief
in particular C implementations. (just to add a contrasting data point,
at my previous employment we had examples o
> Does anyone have pointers to *nice* interfaces for doing this? I don't
> care which OS, but I'd like to not have the implementation I'm
> requesting suck because I missed some gotchas that someone else already hit.
paul lalonde's request is a good one, but i think a useful qualification
is th
> Correct me if I'm wrong here, but don't these require extensive run-time
> support, in addition to compiler support? Will the run-time libraries
> also be linux libraries running under a compatibility layer?
yes, but the final answer to the second question is unclear,
depending on the library
> Just a dumb question, as i'm totally out of this business, it is easier to
> write an emulator than translate the applications to plan9 c ? (for example)
> or to write (or port) the C++ and Fortran compilers and related tools?
it is easier (in both cases), but it's also not the point. applicat
> Also, if you do create a Plan 9 partition and
> then prep it to make subpartitions (you'd have
> to use 9vx, copying the binaries from sources),
> then p9p venti can handle those partition names
> too: /dev/sda1:arenas assuming /dev/sda1 is a
> Plan 9 fdisk partition containing a subpartition
> n
> Within 9vx, something is printed which looks like the same
> message from the drawterm'd crash, but goes away before I
> can be sure.
This is just an acme font bug that causes acme to suicide.
In the latest 9vx I had left turned on the flag
that causes core dumps when 9vx panics,
but I forgot t
> Is this just 'listen -N' in fossilcons(8)?
> Given that listen and users are fossil-wide, rather
> than fsys-wide, it seems like duplicating what
> sources is doing at a "normal" Plan 9 installation
> would involve running a second fossil. If -N were
> on open (which seems reasonably close to ope
> I'm running a p9p venti server under Linux using several
> (small by current standards) physical drives as my arena
> pool. I got a 500GB external USB drive to use as a backup
> of the arenas. But here's the gotcha. The number of blocks
> per cylinder on the 500GB drive isn't the same as the o
On Thu, Jul 31, 2008 at 5:53 AM, Philippe Anel <[EMAIL PROTECTED]> wrote:
> Can you tell us why some things are impossible to scale with 5000 posix
> threads (and easy to scale with 5000 plan 9 style threads) ?
the trivial stuff you deal with first, like the default 8MB thread
stack which makes th
> > - Is this going to cause any problems?
> > - Is there a better way to handle this?
>
> could you use disk/prep instead of disk/fdisk?
> prep should work in this situation as long as the
> sector size on both drives is the same.
I don't think so. Unless it's been added recently,
p9p doesn't h
> Obviously depending on the C calls involved, some are re-entrant and some
> are not, and that makes a rather large difference too. You don't want to
> call strtok from two different threads (unless you have thread local storage
> available, then it might be safe).
malloc? it should be availabl
> - Is this going to cause any problems?
> - Is there a better way to handle this?
could you use disk/prep instead of disk/fdisk?
prep should work in this situation as long as the
sector size on both drives is the same.
- erik
I'm running a p9p venti server under Linux using several
(small by current standards) physical drives as my arena
pool. I got a 500GB external USB drive to use as a backup
of the arenas. But here's the gotcha. The number of blocks
per cylinder on the 500GB drive isn't the same as the other
small
Looks like maybe they should turn accel off? I think this worked for me for
VMWare, but that doesn't mean that'll work here too... worth a shot anyway.
Dave
On Thu, Jul 31, 2008 at 7:09 AM, andrey mirtchovski
<[EMAIL PROTECTED]>wrote:
> I was going to try it until i saw this:
>
> http://forums.v
On Thu, Jul 31, 2008 at 7:11 AM, Philippe Anel <[EMAIL PROTECTED]> wrote:
> That's almost what they do with KSE in FreeBSD (or Scheduler Activation
> in NetBSD) right ?
>
> Phil;
>
KSEs were a way to make things that were not processes or threads in
particular cooperatively scheduled with user-s
On Thu, Jul 31, 2008 at 7:01 AM, erik quanstrom <[EMAIL PROTECTED]>wrote:
> > I've been writing a lot of Erlang code lately, and I keep thinking about,
> > but not having too much time to do much about, wanting to have a runtime
> for
> > the libthread "threads" that could auto-schedule them to li
That's almost what they do with KSE in FreeBSD (or Scheduler Activation in
NetBSD) right ?
Phil;
I've been writing a lot of Erlang code lately, and I keep thinking about, but
not having too much time to do much about, wanting to have a runtime for the
libthread "threads" that could auto-sc
I was going to try it until i saw this:
http://forums.virtualbox.org/viewtopic.php?t=2991
looks like others have got plan9 going on it.
On Wed, Jul 30, 2008 at 11:10 PM, William K. Josephson
<[EMAIL PROTECTED]> wrote:
> Has anyone in these parts experimented recently with VirtualBox?
>
>
> I've been writing a lot of Erlang code lately, and I keep thinking about,
> but not having too much time to do much about, wanting to have a runtime for
> the libthread "threads" that could auto-schedule them to libthread "procs",
> in much the same way Haskell "sparks" may end up real threads, o
On Thu, Jul 31, 2008 at 5:53 AM, Philippe Anel <[EMAIL PROTECTED]> wrote:
> Can you tell us why some things are impossible to scale with 5000 posix
> threads (and easy to scale with 5000 plan 9 style threads) ?
> Is this specific to posix or linux ? Or maybe you will write a paper on
> this ?
>
>
hello
thanks for the clarifications Eric and Ron ☺,
btw, if you're planning to go to Greece to the 3rd. iwp9, i would love to see a
real
sheet of these ones:
http://www.atkielski.com/PDF/data/fortran.pdf
☺
slds.
gabi
> On Wed, Jul 30, 2008 at 10:25 AM, <[EMAIL PROTECTED]> wrote:
>>
>> i'
hello
thanks for the clarifications Eric and Ron ☺,
btw, if you're planning to go to Greece to the 3rd. iwp9, i would love to see a
real
sheet of these ones:
http://www.atkielski.com/PDF/data/fortran.pdf
☺
slds.
gabi
> On Wed, Jul 30, 2008 at 10:25 AM, <[EMAIL PROTECTED]> wrote:
>>
>> i'
Can you tell us why some things are impossible to scale with 5000 posix
threads (and easy to scale with 5000 plan 9 style threads) ?
Is this specific to posix or linux ? Or maybe you will write a paper on this
?
Phil;
- Original Message -
From: "ron minnich" <[EMAIL PROTECTED]>
To: "
On Wed, Jul 30, 2008 at 18:36, Roman V. Shaposhnik <[EMAIL PROTECTED]> wrote:
> As Russ, quite rightfully, pointed out: mmap() means different things
> to different people. The tragic part is, that it tries to do lots of
> things but it doesn't do anything particularly well. Personally, my
> experi
36 matches
Mail list logo
