Le Forgeron wrote:
> And it seems it is never initialized (only one reference) explicitely, so 
> only the constructor of vfesession might in fact create that mutex.

the mutex is a class in its own right and thus has its own constructor,
which is invoked when vfesession is constructed. so that's not likely to be
the issue.

looking at the code, I can see one possibility that jumps at me: it may be
I misread the usage for boost::condition at the time, or simply slipped up,
but it appears that if the worker thread created via 'new boost::thread()'
 at line 1082 of vfesession.cpp#23 was able to run as far as its call to
'm_InitializeEvent.notify_all()' (line 638) *prior* to the next line of
vfeSession::Initialize() executing, the notify_all would have no effect and
the subsequent timed_wait would time out*. (if this happens at all, it
would be more likely to occur on machines with a single core).

to test this theory, please try adding a printf to line 1082 which reads
like this:

  fprintf(stderr, "%p %d\n", m_Frontend, m_BackendState);

so you will then have:

  m_WorkerThread = new boost::thread(vfeSessionWorker(*this));
  fprintf(stderr, "%p %d\n", m_Frontend, m_BackendState);
  if (m_InitializeEvent.timed_wait(lock, t) == false)

if all is well you ought to get 0 and 0 as the output. if you get an
initialized pointer and a backend state that's not 0, it's highly likely
that what I am describing is what is happening (if so, it won't be
difficult to fix, and probably should be irregardless of the outcome of
your test).

-- Chris

* I do note I have a 'FIXME' on the worker thread code at around that
  point, indicating I was not happy with it at the time (e.g. just from
  glancing at it now I see the exception thrown at line 636 is unlikely to
  ever be seen; throwing it would also trigger a timeout in the waiting
  code; and what's worse m_LastError is not set in that case. yuck!).

Post a reply to this message