I didn't read your message seriously,
but in my first glance, what you want to seems to be asychroneous threads.
Why don't you use Event module of threads library?
It's a Concurrent ML.

---
SooHyoung Oh
----- Original Message -----
From: "Likai Liu" <liulk@bu.edu>
To: <caml-list@inria.fr>
Cc: "Likai Liu" <liulk@acs.bu.edu>
Sent: Tuesday, July 15, 2003 5:55 AM
Subject: [Caml-list] PortAudio on ocaml


> Hello,
>
> I'm trying to evaluate on porting PortAudio API to O'Caml, which would
> enable an entire genre of sound applications being written in this nice
> language. What concerns me is that PortAudio uses asynchronous callbacks,
> much like signals, to tell the application that some audio sample has
> arrived, needs to be played, or both. I looked at the signal.c of asmrun
> and byterun and found out that signals are normally deferred if it
> interrupts a running O'Caml program until a garbage collection cycle
> occurs. It doesn't seem fesible to have these real-time audio callbacks
> implemented this way; threads seems to be the only way.
>
> If I were to enforce using threads semantics, then the synchronization
> issue might have some light. However, the original PortAudio API is meant
> for a program to continue its execution when callback keeps coming.
> Depending on the implementation on a certain platform, it might interrupt
> the program completely while it processes the callback, or the program
> might run concurrently with the callback on different threads. Since only
> one O'Caml section can hold the global mutex lock at any given time, it's
> likely that the callback will block trying to acquire the lock in either
> cases. It seems necessary to change the PortAudio interface on O'Caml to
> block the running program while the audio transaction is carried out.
>
> Before I make such a radical decision, I'm wondering if there is a better
> solution. A possibility after soul searching the source code of threads is
> that, in the case of bytecode, when a thread does Unix.select, the thread
> scheduler would let go the lock momentarily so the callback doesn't block
> forever; in the case of native thread, when a thread calls Threads.yield,
> then the lock is released momentarily. I'm not sure if it's a good idea to
> rely on these deep internals of O'Caml, or maybe it's better to stay on
> the light side, that is, restrict the API for workaround, instead. What do
> the O'Caml developers say about this?
>
> There is a simplified interface of PortAudio called Pablio that doesn't
> use the callback, but a conventional blocking I/O style read/write
> functions. Pablio interface is straightforward to implement. So at least
> the current plan is to get pablio working first, and leave the actual
> PortAudio API unimplemented with some provided interface stub for
> reference purpose.
>
> liulk
>
> -------------------
> 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
>

-------------------
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