[Caml-list] vmthreads...

[Caml-list] vmthreads...

[Jonathan Roewen]

Hi,

Just a simple question: how does Thread.critical_section ever get set
to false? I see mutex.ml sets it to true, as does condition.ml, but
neither set to false.

Does this mean pre-emption won't work as soon as a mutex is locked?
This -might- explain the weird lockup I'm experiencing with my OS/NIC
driver, as when it locks up (there's no fatal exception being
propagated) not even the timer interrupt which does preemption seems
to do anything (the keyboard driver -should- still run, for instance).

Jonathan

Re: [Caml-list] vmthreads...

[Jonathan Roewen]

> Hi,
>
> Just a simple question: how does Thread.critical_section ever get set
> to false? I see mutex.ml sets it to true, as does condition.ml, but
> neither set to false.

Ah, I see Thread.sleep sets it back to false.... however, I still have
the feeling something is going wrong in the threading system...

Jonathan

Re: [Caml-list] vmthreads...

[Jonathan Roewen]

Let me show you the code that is causing the problems ;-)

http://rafb.net/paste/results/bk9vcK29.html -- figured less painful
than pasting inline ;-)

Anyways, what happens is I create an instance of a functor that builds
a driver. When things don't lock up, it all runs fine. However, every
couple of runs, it easily locks up -- nothing responds.

Here's a dump of a sample session of my debugging statements:

isr_contents = %x
write: sent...
write: sent...
write: sent...
write: sent...
in ISR...
isr_contents = 4 (* => transmit_ok bit is set *)
tx queued packet (* 'may' does this if there is a packet queued *)
in ISR... (* we call ourselves again, because isr_contents <> 0 *)
isr_contents = 4 (* I guess another packet has been transmitted.. *)
tx queued packet
in ISR...
isr_contents = 0 (* so we can now return *)
in ISR..
isr_contents = 0
write: sent...
(* system completely locked up/dead *)

Jonathan