-thread needed to compile about batteries-included

[thelema]

Nope, doesn't work. :( I don't have any solution for this - is it possible?

[mdekstrand]

What happens if you add the mt predicate to the byte and native archive lines? That should prevent the library from linking in when you don't use -thread, forcing a link failure. Is that sufficient?

Would it be useful to have multithreaded and non-multithreaded versions, so that single-threaded programs could use as much of Batteries as is useful in that context? Or is it currently a design goal to have Batteries a single one-size-fits-all package?

[thelema]

Batteries used to have multithreaded + non. I removed this feature to simplify the organization of the project and the build system. If I could have threads as optional, I'd be happy, but this looks like it'd take invasive changes.

[mdekstrand]

I have committed changes which seem to do this to the no-mt branch on my fork. It builds everything but BatMutex and BatRMutex without -thread, builds those with -thread, and creates a batteries-mt library with the threaded stuff. It adds the requirement for client code to open Batteries_mt to get access to the stuff that requires threading (near as I can tell, only BatMutex and BatRMutex).

Batteries_mt also sets up the various locks throughout Batteries (in BatIO, BatUnix, and BatPervasives) to use BatMutex rather than Concucurrent.nolock.

[thelema]

This looks like a good solution - I've pulled your changes into the master git trees. Could you post to the batteries list for people to test this? I'd love to release 1.1 with this update (and the docs that I need to finish)

[mdekstrand]

Done.

I found one problem building the single-threaded program I have - there was no non-mt requires line, so the dependencies didn't get pulled in. My master fixes this.

[mdekstrand]

Is this a 1.1-level change, or a 2.0? As it sits (when I committed), code using Mutex and RMutex required a source-level change (open Batteries_mt rather than open Batteries). With some build system magic, it would be possible to make it non-breaking though. Should I look in to trying to do that?

[thelema]

hmm, I fear it is a 2.0 level change, as we're removing the old compatibility. Could we do the opposite - have [open Batteries] open the threaded code, and [open Batteries_uni](or some other name) do single-threaded?

[mdekstrand]

It would be possible to do that, but I think long-term Batteries and Batteries_mt are better choices if separate modules are needed.

I think it would be possible to do some build system and ocamlfind trickery so that when -thread is used, the Batteries module includes Mutex and RMutex. It might involve duplication of some cmi/cmx files, but hopefully not.

[thelema]

Agreed in the long term. For the ocamlfind trickery - I think all we need is to make a batteries_mt.cm[x]a that doesn't have a module Batteries_mt, but has Batteries which contains all that Batteries_mt contains now. There is the problem of having a .cmi file for each... hmm...

[mdekstrand]

Yes. The trickery is in accomplishing the following:

• Building two different versions of the Batteries module, one for each .cm[x]a (build system magic).
• Pulling in the appropriate batteries.cmi file (ocamlfind trickery).

[mdekstrand]

Upon further thought, the trickery I describe will not work well. If you have a module built without threads and try to link it with threads, they'll see different Batteries modules and thus be incompatible. The Batteries_mt/Batteries distinction (or, at present, vice-versa) is a necessary evil.

[mdekstrand]

Added backwards compatibility notes

• Document BatLogger change.
• Document Batteries_mt/Batteries_uni situation. Closed by 7f06765.