* Fixed BLooper::ReadMessageFromPort(). If ReadRawFromPort() failed,
there was nevertheless a message created and dispatched.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10738 a95241bf-73f2-0310-859d-f6bbb57e9c96
flag was reported by Bill Hayden).
I fixed only this method, and nothing else, but please have a look at how
I did it, and apply the same fixes, thanks!
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@6902 a95241bf-73f2-0310-859d-f6bbb57e9c96
than one looper.
Implemented UnlockFully(), and changed destructor and Quit() to use it.
Reordered the destructor slightly so as to delete fLockSem *after* the call
to UnlockFully().
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@869 a95241bf-73f2-0310-859d-f6bbb57e9c96
IsMessageWaiting() test #3. fLastMessage wasn't getting initialized to
NULL on construction, and the random value was finally biting me. All
better now.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@856 a95241bf-73f2-0310-859d-f6bbb57e9c96
instantiation of BRoster from BArchivable, line 323, as per Tyler's
mention. =)
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@852 a95241bf-73f2-0310-859d-f6bbb57e9c96
work very well with BApplication and has some issue with plain loopers
too.
* DispatchMessage(): _QUIT_ doesn't delete the object any longer. The
looper thread simply falls through the dispatching loop and deletes
the object.
* Caused by not killing the looper thread in the destructor, Quit() had
to be adjusted. When called from the looper thread the thread exists.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@576 a95241bf-73f2-0310-859d-f6bbb57e9c96
removed. The old static BLooper functions for managing the looper list are
still there, but they are officially deprecated. The approved interface
for this information is BPrivate::BLooperList, accessible via the global
BPrivate::gLooperList variable. Being as it lives in BPrivate, it is for
API-internal use *ONLY*. User apps use it to their own risk.
Also added a small test to make sure that the size of BLooper stays the
same. I will probably add this to other classes as well; doesn't hurt to
be safe. =)
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@572 a95241bf-73f2-0310-859d-f6bbb57e9c96
worked under R5 but only sometimes for OBOS. Answer: the OBOS
implementation of BLooper was attempting to lock itself prior to fetching
the message from the queue. I moved the lock attempt after the fetch and
it worked the same. I realized that if the system was loaded heavily
enough, the assert might still fail simply because the looper would not had
enough time to get to the fetch (thereby emptying the queue), making the
assert pretty useless. Given that it was originally there as a probing
test (rather than as an integral part of the unit test), there is no real
need for it anyway, so it is no longer used.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@250 a95241bf-73f2-0310-859d-f6bbb57e9c96
Adi Oanca