"Mikkel Fahn=F8e J=F8rgensen" <mikkelfj@...> writes:
> coThreads looks interesting!
Glad to hear :)
> I tried the raytracer example on OS-X - but ray_nocol.nath.opt and
> ray_col.nath.opt immediately results in "Illegal Instruction".
> .proc.opt and .nath (bytecode) works.
I'm totally alien to Mac and don't have a testing environment at hand. Howe=
the two ray* programs don't make much use of the coThreads extension, most
parts of them are written in plain OCaml (spawn* functions are actually a e=
When I searched "Illegal instruction" through the OCaml mailing list achiev=
found that most of this kind of problems are related to OCaml runtime rather
than user space libries. Especially, I found the bug report , which seem=
be exactly related:
> Another question:
> I'm not sure how coThreads will interact with memory mapped files, backgr=
> I am working a mmap based storage written in C, linked to OCaml where
> I'm actually about to do something related with transactional memory,
> primarily for crash recovery (as in: data not modified by other
> thread, but by inconsistent disk write) and possibly also for
> multicore operation. Here the mmap image is a mostly up to date
> representation and the transaction log is the authoritative storage.
> If I used coThreads with proc, I assume I will either get a shared r/w
> view of the mapped file - but I guess it both depends on how I create
> the mmap and how the process is spawned?
Knowing quite little about the implementation of your application, I would
predict two problems here:
- coThreads STM involves taking snapshot of transactional variables (OCaml
values). In your case, it seems that the real storage is in C side and t=
OCaml-side values are just descriptor (possibly unchanged?). So I fail to
see what kind of benefit you can get here.
- I have some experience with Bigarray which is based on mmap. It's unlike=
in this model, to consider each array element as independent OCaml value=
with STM, there is an efficiency problem here: if we declare the whole a=
as one transactional variable, the update of any element inside the array
will lead to the update of the whole array hence inefficient; instead, i=
take the elements inside the array as a set of transactional variables a=
update them independently, the efficiency is dramatically improved. The
problem is that, a Bigarray can hardly considered as a set of independen=
array elements (On the other hand, you can do that, but the most functio=
are no longer directly applied to Bigarray itself. You can actually read
Bigarray values into OCaml values and operate on OCaml values then write=
result back as Bigarray values, however I'm not sure if this is what you=
> Are you considering how to get processes working with Windows?
For now, the coThreads implementation depends on some *nix only system calls
such as pipe, so I wouldn't expect it to work on Windows at the
moment. However, it's possible to substitute them with other Windows
workarounds in the future.
> I'm fairly sure STM can't be used directly for my storage although
> some principles are related, but it might solve my need for higher
> level concurrency control including process coordination and provide
> atomic operations on lower level structures.
Considering your application, there are also traditional mutex and condition
modules in the process engine, compatible with the standard ones for
threads/vmthreads. On the other hand, you shouldn't have much difficult to
implement your own control structure in term of STM.=20
I'm currently working on the following extensions for coThreads:
- special thread identifier: Cothread.anyone and Cothread.everyone
- raise exception in certain thread(s): raise_in
- Timer module: set timer, schedule and timeout
- Lock module: fine-grained reader/writer locks
> Network operation would be interesting, no so much for immutable data
> access, but rather as a means to coordinate heterogene cooperating
> processes such as a db drive, a db transaction logger and a cache
> server. This could happen through low bandwidth shared mutable data.
> btw.: the web menu is broken on this page:
It's a problem of the sourceforge web hosting. Usually it works again if you
reload the page.
I also CC the reply to coThreads mailing list, hope you don't mind. You may
also consider joining it if interested.
All the best