FreeLists / openbeosnetteam / [openbeosnetteam] Re: Resize area

["David Reid" <dreid@xxxxxxxxxxxx>]

Sorry Philippe, no go with that option either. I'll try B_LAZY_LOCK...

Could it be the size of the libraries? Be's libnet.so is only 170,000 but
ours is over 1MB now!

david

----- Original Message -----
From: "David Reid" <dreid@xxxxxxxxxxxx>
To: <openbeosnetteam@xxxxxxxxxxxxx>
Sent: Thursday, May 02, 2002 9:37 PM
Subject: [openbeosnetteam] Re: Resize area


> OK, I'm trying your fix but seem to have triggered a KDL in how we call
> select()! Eeeekkk - is nothing ever easy about select???
>
> david
>
> ----- Original Message -----
> From: <philippe.houdoin@xxxxxxx>
> To: <openbeosnetteam@xxxxxxxxxxxxx>
> Sent: Thursday, May 02, 2002 2:47 PM
> Subject: [openbeosnetteam] Re: Resize area
>
>
> > I'm looking thru the code, hoping to have some flash on our current
> > Public Enemy #1 bug origin, which seem to be related to memory leaks
> > and/or exhaustion.
> >
> > On this last topic, I think this line is not required AND can quickly
> > exhauste the kernel areas space:
> >
> > server/net_server/pools.c:
> > #define AREA_FLAGS      B_CONTIGUOUS|B_FULL_LOCK
> >
> > First, these constants ARE not bit-flags.
> > It should be or B_CONTIGUOUS or B_FULL_LOCK, but not an or-combination.
> > Btw, B_CONTIGUOUS imply B_FULL_LOCK.
> >
> > Next, B_CONTIGUOUS is *really* not wanted here.
> > Nor necessary.
> >
> > It's only used/needed by hardware drivers code, mostly to create an
> > area mapping in virtual memory some hardware physical memory.
> > Best example is a video card frame buffer, that in BeOS a driver should
> map (using create_area("vfb", &fb_addr, B_EXACT_ADDRESS, fb_size,
> B_CONTIGUOUS, B_READ_AREA | B_WRITE_AREA) into an area.
> > Soundcard buffers are another examples...
> >
> > B_CONTIGUOUS can be a real evil on physical memory fragmentation,
> > and could complexify a lot the VM manager job.
> > Maybe to a failure point.
> >
> > We should try with this value:
> > #define AREA_FLAGS  B_FULL_LOCK
> >
> > We could also allow the stack to work under an even heavier global
memory
> > usage if we use B_NO_LOCK, that is let's our pools'ed blocks to
> > be swapped as needed.
> > But, in this case, care should be taken to never access these areas from
> interrupt handler/timer, because the VM support don't works in
> > interrupt level. As we've moved back to thread'ed timers, our stack
don't
> > have any more interrupt-level code, so...
> >
> > -Philippe
> >
> >
>
>
>