Stumped on C threading code

[purevoid]

Hi,

I have a two-layer threading system. First is a co-op C layer, and second is a co-op OCaml layer built on top of this C layer.

All the interesting parts are all in C, and I'm having trouble finding out why my thread->data is NULL, as this is only set as NULL in the create_thread function.

Every created ocaml thread sets data to the current ocaml thread struct, and I've checked that they're not NULL, so I'm very confused.

Could some people please provide some extra eyes to go over my thread code please?

The file is at http://moonbeam.purevoid.org/~jonathan/threads.c.

Jonathan

[purevoid]

I should add some context on what's happening:

I have an ocaml thread that polls irqs, and a thread for running my keyboard handler.

My keyboard handler thread calls Irq.wait, which in turn calls Thread.self() .. this jumps into C land, only to find curr_thread (for ocaml threads) is NULL.

As it turns out, in thread_leave_blocking_section (only called by ocaml threads), the curr_thread in the plain C thread->data member is NULL in an OCaml context. This should not be possible.

So, unless there is some strange way that an ocaml thread is executing outside of its context, this should be impossible...

[Pype.Clicker]

Code: Select all

CAMLprim value caml_thread_self(value unit)
{
   //curr_thread = current_thread()->data;
  if (curr_thread == 0L) {
     print_exception("thread.self failed");
     caml_invalid_argument("Thread.self: not initialized");
  }
  return curr_thread->descr;
}

seems weird to me ... esp. the fact curr_thread assignment is commented out.

[purevoid]

That's because that line shouldn't be there. I was doing that to make sure I was getting the current thread, but it didn't help one bit.

As you can tell by the string argument, curr_thread can only be NULL before ocaml thread machinery has been initialised.

If it's of any help, the rest of the source code is at http://moonbeam.purevoid.org/~jonathan/src/.

[Pype.Clicker]

well, the best piece of advice i can give you is to spice up your code with asserts on the curr_thread value so that you discover what function makes it null.

If you have the option, you can watch its value in a debugger ...

I'm not certain i completely got how your interrupts are actually handled, but i'd fear too that some handler has turned current_thread to NULL because it was in C, but failed to restore current_thread to its previous value when it left the handler.