Am 01.11.2012 19:53, schrieb Rob T: > > I'm relatively new to D but making good progress with it after a very > slow start (it is a very complex language). Some of what I am working on > shares similarities with what vibe.d is doing, so I'm very interested in > how vibe.d is progressing. > > vibe.d looks like a rather complex project, so I am wondering if you've > made use of any shared libs with D (i.e., .so and/or .a compiled for PIC)? > > I know that the druntime will not link as-is without a rebuild to enable > PIC, so have you found this to be a problem, not using shared libs, or > have you rebuilt druntime to allow for it?
I haven't used shared libs in conjunction with vibe.d, but in a LLVM based compiler project that was compiled as a DLL (where PIC is not required). For OS X I dodged the PIC problems by compiling it as a static library. But TLS required a lot of tweaking on GDC+Win64 and remained very fragile. Before getting to the root of this and fixing it, development priorities shifted and later I left the company. So unfortunately I can't really offer really useful insights here apart from confirming the already known problems. > > I'm also wondering how the co-routines are working out with vibe? I > thought of using them, but my current design will be using message > passing instead, where the code is broken up into small parts to perform > the co-processing. When messages are received at a location, the code > fragment executes. I've done this before in C++ and it worked great, but > with D I now have an alternative using fibers, but I have no exerience > with using them. They are working out really well and are a great help to concentrate on concepts rather than how to implement them. I'm also using them in a Windows GUI application, where they are mixed with window message processing, and it really helps to simplify some parts there, which were formerly implemented as threads (with error prone locking/lockless data sharing) or as fragmented jobs with an explicit state (complicating the algorithm). Another place I would like to have/add std.concurrency style message passing on top though, as that sometimes is actually quite convenient and of course it's also a very safe way to handle communication between fibers that are running on different threads - provided that only immutable/shared/unique data is sent, of course.
