[openbeos] Re: BLocker in disk_device_manager (and more...)
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 23 Sep 2003 21:28:25 +0200
On 2003-09-23 at 14:35:40 [+0200], Axel Dörfler wrote:
> "Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx> wrote:
> > this is the wrong list, but I am too lazy to add myself to the
> > StorageKit list and
> > this also concerns other modules that include BLocker in kernel land
> > (using
> > disk_device_manager's Locker.h/cpp):
> > Should BLocker not use kernel_cpp.h/cpp? Otherwise there are linker
> > errors
> > saying that __bulidin_delete is not defined (is this used by the
> > destructor?).
Yep. The class -- and RWLocker probably, too -- will be made kernel safe and
moved to .../kernel/util at some time, though. Their current location is an
indication for the fact, that they are private to that module and not to be
used by others. :-)
> Right, everything that uses C++ in the kernel should use util/
> kernel_cpp.h. BTW do we have to introduce the "B" prefix in the kernel
> space?
I'd say, some namespace isn't that bad an idea.
On 2003-09-23 at 14:54:34 [+0200], Waldemar Kornewald wrote:
> > Right, everything that uses C++ in the kernel should use util/
> > kernel_cpp.h.
>
> May I fix this, please? :))
Mmh, you may do, so, but as I said, it's not really intended to be public.
On 2003-09-23 at 16:19:06 [+0200], Waldemar Kornewald wrote:
> > "Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx> wrote:
>
> > > > BTW do we have to introduce the "B" prefix in the kernel
> > > > space?
> > > BLocker will be replaced by other kernel land classes, anyway (too
> > > heavy?).
> > > No need to break the source twice.
> >
> > What do you mean by "too heavy"?
>
> Too much functionality that is not needed most of the time.
> A simple Benaphore class would work in most cases. Only when you want to
> allow relocking by the same thread without aquiring the semaphore BLocker
> is needed.
That's exactly the point, why it is there: I need that functionality (or at
least use it for convenience). The `too heavy' argument may apply for the
reserved fields -- the thing is private to the kernel, so we don't need to
care about binary compatibility.
We may want to make a couple of methods (the one and two liner at least)
inline, too.
CU, Ingo
PS: Wow, I love Beam, the feature for replying to multiple mails just rocks.
Other related posts:
