caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] Interfacing C threads with Ocaml - weird bug
@ 2002-04-02  8:02 ronniec95
       [not found] ` <15531.9799.220007.210452@akasha.ijm.jussieu.fr>
  0 siblings, 1 reply; 2+ messages in thread
From: ronniec95 @ 2002-04-02  8:02 UTC (permalink / raw)
  To: caml-list

Hi guys,

I've written a Ocaml interface for an C-API. It sets up some parameters
(all works) then starts a thread pool (C). I then call a mainloop
function that contains a while loop that, upon receiving a request
dispatches the event to a C callback.

OCAML:
let receiver () = 
                    let _ = Tib.opent ()
                    and tport = Tib.create_transport "" "" ""
                    and queue = Tib.default_queue () in
                        let event = Tib.create_listener queue "testcb" tport "foo" in
                            print_string "Listening...\n"; flush stdout;
							(* This call loops and never returns - but should dispatch events to some callback *)
							Tib.queue_dispatch queue; 

C:
value ml_queue_dispatch(value queue)
{
	/* This is called from OCAML and never returns */
	while(tibrvQueue_Dispatch(TIBRV_DEFAULT_QUEUE));
}

/* This function is called from the above dispatcher on an event  - it's
 * called on a thread taken from a pool (not same as dispatcher/caml.
 * Note there is no call back to Caml here */
static void caml_callback_interface(tibrvEvent event,tibrvMsg msg,void* closure)
{
	printf("Callback called!\n");
}

Question: Why would it take in the order of 20-30 seconds for the
callback to be triggered rather than immediate as is the case when I've
written identical wrappers for perl/java/C++. I'm guessing something
about thread yielding control, but this should happen automatically
since it uses pthreads internally?

I've tried putting the Tib.queue_dispatch call in its own thread
(started by CAML) or having a new C thread created when the C function
is called, but both show identical symptoms. This is a proprietary API
so I have no access to the raw socket or thread dispatching that goes
on. However I do know it is standard posix threads being created inside
the C code.

Any ideas (very) helpful.

Thanks

Ronnie
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Caml-list] Interfacing C threads with Ocaml - weird bug
       [not found] ` <15531.9799.220007.210452@akasha.ijm.jussieu.fr>
@ 2002-04-03 17:20   ` ronniec95
  0 siblings, 0 replies; 2+ messages in thread
From: ronniec95 @ 2002-04-03 17:20 UTC (permalink / raw)
  To: Olivier Andrieu, caml-list

On Wednesday 03 April 2002 at 16:43PM, Olivier Andrieu attributed that:
>  ronniec95@lineone.net [Tuesday 2 April 2002] :
>  >
>  > Hi guys,
>  > 
>  > I've written a Ocaml interface for an C-API. It sets up some parameters
>  > (all works) then starts a thread pool (C). I then call a mainloop
>  > function that contains a while loop that, upon receiving a request
>  > dispatches the event to a C callback.
>  > 
>  > OCAML:
>  > let receiver () = 
>  >                     let _ = Tib.opent ()
>  >                     and tport = Tib.create_transport "" "" ""
>  >                     and queue = Tib.default_queue () in
> 
> (...)
> 
>  > Any ideas (very) helpful.
> 
> Hi, maybe you've solved your problem already but I have a comment on
> your code : 
> you use ? let _ = ... and tport = ... and queue = ... ?. Now I'm not
> sure in which order the evaluation takes place in case of ? let
> ... and ... ? construct : actually the manual says it's
> "unspecified". Since Tib.opent should be evaluated before everything
> else I guess, I'd say it's better to use ? let _ = Tib.opent () in let
> tport = ... ?.

Hmm - it appears to work with either construct, but as you say, it's
obviously incorrect to rely on this. I had assumed that the only reason
you have to use 'in' is when you will be using the result of a previous
calculation.

So I've also fixed this (potential) bug.

> 
> But your threads problem is probably unrelated to this.
> 

Using classic divide and conquer I managed to track down the thread bug
to an incorrect Field(x,y) macro earlier in the initialisation.

Thanks for all the help

Regards

Ronnie

> -- 
>    Olivier

-- 
->=======================================<-
 name:  ronnie m chowdhury 
 mobile:+971-50-566-4437
 tel:	+971-2-681-7600
 fax:	+971-2-681-7900

 addr:   1304, three sails towers
         corniche road west
         abu dhabi
         po box 41876,
         united arab emirates
->=======================================<-
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-04-03 19:52 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-02  8:02 [Caml-list] Interfacing C threads with Ocaml - weird bug ronniec95
     [not found] ` <15531.9799.220007.210452@akasha.ijm.jussieu.fr>
2002-04-03 17:20   ` ronniec95

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).