Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
34 user(s) are online (18 user(s) are browsing Forums)

Members: 3
Guests: 31

billyfish, NinjaCyborg, sailor, more...

Headlines

Report message:*
 

Re: MineCraft (MineTest) work in progress help need it

Subject: Re: MineCraft (MineTest) work in progress help need it
by kas1e on 2021/1/5 19:51:42

@Capehill
Ah, you mean that a usual try and catch (was by some stupid reason think that this is something called exactly try-catch :) ).

Anyway, tried firstly as you say that in thread-native-patch:

int
__gthread_mutex_trylock 
(__gthread_mutex_t *__mutex)
{
  
__internal_gthread_mutex_t *mx = (__internal_gthread_mutex_t *)__mutex;

  
/* Initialize libs */
  
__gthread_once (&libs_onceinit_libs);

  if (
iexec->AttemptSemaphore (&mx->u.i.sem))
    {
      if (!
mx->u.i.recursive && mx->u.i.acquired)
        {
          
iexec->ReleaseSemaphore (&mx->u.i.sem);
          return 
EBUSY;
        }
      
mx->u.i.acquired++;
      return 
0;
    }
  return 
EBUSY;
}


Now, that what we have in output when run testunits for this https://github.com/minetest/minetest/b ... ittest/test_threading.cpp

Quote:

======== Testing module TestThreading
before join
after join
before join
after join
before join
after join
before join
after join
before join
after join
[PASS] testStartStopWait - 485ms
before join
after join
before join


So, it does 5 joins. And seems passed the testStartStopWait(). But then, when it starts to test testAtomicSemaphoreThread() from above-mentioned test_threading.cpp, then it seems to fail again.

Question is: do we deal with first issue now, and meeting with another one in semaphores ? For testStartStopWait test i can see in void TestThreading::testStartStopWait() : for (size_t i = 0; i != 5; i++) { ... } , so maybe indeed correctly works now and we need to approve patch to adtools ?

But then second question, why it stops on second joing from void TestThreading::testAtomicSemaphoreThread():

void TestThreading::testAtomicSemaphoreThread()
{
    
std::atomic<u32val;
    
val 0;
    
Semaphore trigger;
    static const 
u8 num_threads 4;

    
AtomicTestThread *threads[num_threads];
    for (
auto &thread threads) {
        
thread = new AtomicTestThread(valtrigger);
        
UASSERT(thread->start());
    }

    
trigger.post(num_threads);

    for (
AtomicTestThread *thread threads) {
        
thread->wait();
        
delete thread;
    }

    
UASSERT(val == num_threads 0x10000);
}


Does that maybe issue in our semaphores-POSIX implementation? Frederik, maybe you have an idea about the second one, and if we correctly fix now gthread_mutex_trylock() and this one also needs to be added to adtools ?


PS. Was in hope that this fix in thread-native will fix that issue: https://github.com/sba1/adtools/issues/82, but nope, still something else (but also probably close enough to what you find). But our new issue also looks pretty close to that bug report too. Maybe will be just another bug in the native-threading-patch.


PS2. Oh, and what is interesting, the actual game can't start because of the same issue :) I.e. when I click "play game" it shows me in the shell the same "before join, after join, before join" and hang. Just like when I run test_threading and it acts when checking testAtomicSemaphoreThread() :)

At least now I know why the game didn't start (were about to start debugging network code)

Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project