79.x cookies Visitor d-tor question and Issue 2622

[user6294]

Hi

In 58.x I pass a CefRefPtr<CefCookieVisitor> object to VisitAllCookies() of CefCookieManager instance. When Visitor destructor is called, I can see it is being called on the CEF IO thread.

In 79.x the same application code, the Visitor destructor is being called on the CEF UI thread (which I understand is part of issue 2622 network related changes).

I want the destructor to be called on the CEF IO thread as before, by doing a CefPostTask in the destructor when it knows it's on the TID_UI thread.

Is it safe/correct to do that kind of thing.

Thanks

[magreenblatt]

It should be fine provided the CefPostTask doesn’t reference the destructed observer object.

[user6294]

Great, sorry also can do the same to the Visit() calls, I need them to be invoked on the CEF IO thread.

Thanks

[magreenblatt]

Yes, and Visit can keep a reference because the object is not yet destroyed.

[user6294]

Hi,

Thanks for that - I could quiet things to work without the code crashing in the destructor of one of our logging classes. But here's the issue I'm trying to
solve :

We have these (only relevant details included) classes

// (1) Helper Classes

class CookieGetter {
public:
CookieGetter(std::string cookieName, ...);
// . . .
// WIN32 event sync object created with ::CreateEvent() autoreset mode and initially not signaled
AutoResetEvent _finished;
// . . .
};

class Visitor : public CookieVisitora {
public:
Visitor(..., AutoResetEvent & finished,...);
~Visitor();
// keep a ref to _finished from CookieGetter
AutoResetEvent & _finished;
};

====
// (2) threading and visitor

In CookieGetter c'tor (called from CEF UI thread)

CefRefPtr<CefCookieManager> manager = CefCookieManager::GetGlobalManager(NULL);

manager->VisitAllCookies(new Visitor(..., _finished, cookie_name, ...));

In Visitor d'tor (in 58.x is called from CEF IO thread)

Visitor::~Visitor() {
_finished.set(); // set to signaled and allow 1 block thread to run
}

Above classes are used like this :

In MFC message handler to get cookie value :

LRESULT SomeWindowsClass::OnGetCookieRequest(...) {
CookieGetter getter("MY_COOKIE",...);

// blocks on a ::WaitForSingleObject(..., INIFINITE);
// until ~Visitor() is called (on CEF IO thread)
getter.wait();

// at this point, in 58.x we would have the cookie value ready to be read
}

But in 79.x, the Visitor d'tor is now invoked on the CEF UI thread,
so I can't make the getter.wait() block on the event synch object because both the
waiting thread and the thread doing the releasing are the same UI thread now !

Really would appreciate some guidance on this.

Many Thanks again

[magreenblatt]

Don't block threads. Design your code to work asynchronously with posted tasks instead. See here.

[user6294]

thanks

That was the existing design of our app, which I inherited.

I measured the async response time of the value of the cookie from CEF from the initial VisitAllCookies() call, it's only about 10-20mS.
So our MFC main browser thread/CEF UI thread just blocks for a very short time, until the CEF IO thread calls Visitor() d'tor and pulses the WIN32 event object
which the UI thread is waiting on. We've been using this design successfully for last few years so, I was trying to maintain the semantics of
our app<-->CEF API.

I did trying the CefPostTask() to post the Visit() calls back to the CEF IO thread, I saw it working for a while and then the code kept on 0xC0000005 access violation when one of the logging class objects we are using goes out of scope (feels like being destructed twice kind of because of the method calls being
posted between CEF UI/IO threads.

Are there any rules, on holding on to references etc when using CefPostTask.

Thank You