NewLC - HBufC and threads - Comments

Re: HBufC and threads

alh — Mon, 04 Feb 2008 09:55:23 +0100

I'd really recommend you to try them fig7!
I havn't ever felt the need to use one of those horrible HBufC:s since I found out about them.
RBufs are generally very simple and efficient to use, and produce _alot_ nicer code imo.

Re: HBufC and threads

fig7 — Mon, 04 Feb 2008 00:34:35 +0100

Yeah, the RBuf class was introduced because the HBufC class has a few issues (such as the one we've discovered here, for example). However, I've never really felt the need to start using RBuf instead. I think the phrase is "better the devil you know..."

Re: HBufC and threads

lman — Mon, 04 Feb 2008 00:00:17 +0100

Hmm, one idea just came to my mind , maybe I should use RBuf instead of HBufC

Re: HBufC and threads

alh — Thu, 24 Jan 2008 09:17:27 +0100

Yep.. Its just a limitation of the Des function.

The memory of the HBufC is accessible from the other thread, even if they don't share heaps.
If you'd create the pointer descriptor in the same thread as where the HBufC is created, and then pass the pointer descriptor over the thread boundary, it will also work.

Re: HBufC and threads

fig7 — Wed, 23 Jan 2008 22:47:28 +0100

I think you can just use
iSharedBuf = new(ELeave) TBuf<sizeYouWant>;

instead of using HBufC, which as you've discovered seems to be completely unusable if you've got threads with their own heaps. You might also want to think about using RBuf, although I haven't really used it very much so I don't know for sure if that can be used with different threads (and heaps!)

EDIT: Actually I've added another bright idea. Can't you just create the TPtr when you create the HBufC?

i.e. do the following:

HBufC* iSharedBuf;
TPtr iSharedPtr;

Thread 1:
iSharedBuf = HBufC::NewL(100);
iSharedPtr.Set(iSharedBuf->Des());

Thread2:
iSharedPtr = someOtherBuf

EDIT2: You'd need to construct the TPtr with (NULL, 0) and then set it. I'm fairly sure this would work. Actually there's no need to share the HBufC object with the other thread at all, just let the other thread do everything through the TPtr.

Re: HBufC and threads

lman — Wed, 23 Jan 2008 21:15:34 +0100

Des() method calls AllocLen() of RHeap class, but I will try to do this that way which you proposed in @up post

Edit: Currently I'm using TBuf<600> but I wanted to switch to HBufC which would optimize my program a little

Re: HBufC and threads

fig7 — Wed, 23 Jan 2008 21:07:03 +0100

So getting back on topic:

Is there any way to modify ( e.g. assign some new value ) HBufC descriptor which was created in different thread ?

You've got two choices:

1. Use a shared heap
2. Do it manually:

// Get a TPtr to the data
TPtr ptrToData((TUint16*) iSharedBuf->Ptr(), iSharedBuf->Length(), iSharedBuf->MaxLength());

// Modify the data
ptrToData.Append(someotherBuf);

// Update the length in the HBufC
iSharedBuf->SetLength(updatedLength);

And as alh has pointed out you'll need a mutex if there's any chance that the other thread will also want to access the data at the same time. Note that I'm assuming here that calling HBufC::Length(), HBufC::MaxLength() and HBufC::SetLength(), doesn't call any of those RHeap functions!

EDIT: Actually that doesn't work either because there isn't a HBufC::SetLength() function! It looks to me like you've found a really tricky problem. How about not using HBufC and simply creating a TBuf on the heap instead, would that work?

Re: HBufC and threads

fig7 — Wed, 23 Jan 2008 20:41:38 +0100

From the 3rd edition SDK:

This panic is raised by a number of RHeap member functions, AllocLen(), Free(), FreeZ(), ReAlloc(), ReAllocL(), Adjust() and AdjustL() when a pointer passed to these functions does not point to a valid cell.

so where did you get the "It checks if memory cell on which we want to work on belongs to current thread heap or not" bit from?

Maybe internally Des() calls one of those functions, so the panic would make sense if the threads have seperate heaps. In any case what you need to is change the call to RThread::Create() so that you use a shared heap. I do find it quite odd though that something like Des() would actually call one of the RHeap functions. Clearly that's really annoying if all you want to do is write to a HBufC (which may or may not belong to your threads heap).

Re: HBufC and threads

lman — Wed, 23 Jan 2008 20:23:26 +0100

And according to my SDK User 42 has nothing to do with threads!

I didn't write that that it has something with threads, I wrote

... when I call Des() method on it I always get panic User 42. I've take a look on this panic description and it says that this panic is raised by RHeap class. It checks if memory cell on which we want to work on belongs to current thread heap or not.

Re: HBufC and threads

fig7 — Wed, 23 Jan 2008 20:16:05 +0100

Actually what am i talking about!? Your code should be fine regardless as you've only got one object on one heap!

Re: HBufC and threads

lman — Wed, 23 Jan 2008 20:16:00 +0100

Not good, but anyway thx guys

Re: HBufC and threads

fig7 — Wed, 23 Jan 2008 20:12:34 +0100

class CWhatever : public CBase
{
public:
HBufC* iSharedBuf;
};

Thread 1:
iSharedBuf = HBufC::NewL(100);

Thread2:
iSharedBuf->Des() = someOtherBuf;

This should be fine if you have used the version of RThread::Create() that creates a thread using the same heap as the parent (you just pass NULL for the heap ptr IIRC)

"especially raghav_an"

Except that raghav doesn't know what he's talking about whereas alh does. The only major issue with having seperate heaps is that it is sometimes easy to "forget" which thread created an object so you end up calling delete on an object that is on a different thread's heap, which not surprisingly usually ends up generating some kind of panic.

And according to my SDK User 42 has nothing to do with threads!

Re: HBufC and threads

lman — Wed, 23 Jan 2008 19:00:55 +0100

Sorry guys but I think that you started loosing point of my question. So I will ask again, giving you more info:

In first thread I create HBufC object. In second thread I want to write some data into it but when I call Des() method on it I always get panic User 42. I've take a look on this panic description and it says that this panic is raised by RHeap class. It checks if memory cell on which we want to work on belongs to current thread heap or not. So is there any way to around this limitation ?

Re: HBufC and threads

alh — Wed, 23 Jan 2008 13:40:51 +0100

On the other hand, I agree that if your child thread has no communication with the parent thread it may be better to use a seperate heap (so that the memory is freed if the thread panics). Personally though I never use child threads that don't have some form of communication with the parent. Parent threads shouldn't really disown their children, at the very least they should "logon"...

The problem is that "logon" in itself doesn't solve all problems.
You also need some way to get the pointers to all allocated cells allocated by that thread, and manually go through them and call "delete" on all of them.
Could possibly be done with smart usage of the cleanupstack, or some other way to pass a base pointer to the tree of all allocated cells by that thread to the main thread so it can clean it up, but most people seem to forget this.
The normal cleanup wont happen "automagically" when the thread panics.

If you let the thread has its own heap, that whole chunk containing the heap will be freed when the thread dies, so no need to clean it up manually, so the problem solves itself...

Re: HBufC and threads

alh — Wed, 23 Jan 2008 13:32:39 +0100

If the thread has it own heap then it is not possible to access the objects present in another threads heap, even if both threads are in same address space.
If the thread tries to access any memory from another heap there will be KERN-EXEC 3 panic for access violation.

No. You wont.
If you get Kern-Exec:s when trying to share objects between threads, it is not because of memory violation, but other reasons.
(One classic is Kern-Exec 0 because handles can't be shared between threads unless specifically created to be shareable)
The process is the unit of memory mapping, the OS will not remap your virtual memory when switching between threads.
(Thats part of the definition of the difference between a thread and a process)

I'm not just saying here, I have production code running that uses that exact fact.

HBufC and threads

lman — Tue, 22 Jan 2008 17:58:00 +0100

Is there any way to modify ( e.g. assign some new value ) HBufC descriptor which was created in different thread ?