On Thu, 23 Apr 2015 12:55:09 GMT, Charles wrote:

On Wed, 22 Apr 2015 16:48:10 GMT, Charles wrote:

That said, it only loads correct about half the time (probably a bit less). For some reason it returns a 200 OK message before the page finishes loading one the diet templates. I do not have this problem when I'm not using std.parallelism and I just run the queries serially.

A bit more on what appears to be going on when it fails:

  1. I run through the first five queries using scopedTask as I've described.
  2. The last query I have running in the main thread.
  3. Page begins to load the diet template.
  4. It may or may not load every row from each query, seemingly non-deterministic.
  5. Sometimes execution stops, and the template ceases loading other blocks completely.

For instance, on the following code, it'll never load the blocks scripts: 

block datatable
    table#dataTable.display(cellspacing="0", width="100%")
        thead
            tr
                th ID
                th Name
                th Creator
                th State
                th Stage
                th Actions
        tbody
            - foreach (row; data)
                - auto rowArr = row.toAA;
                tr(data-username='#{rowArr["username"]}', data-project='#{"project"}', data-state='#{rowArr["state"]}', data-workflow='#{rowArr["workflow_name"]}')
                    td.text-center #{rowArr["sim_id"]}
                    td #{rowArr["sim_name"]}
                    td.text-center #{rowArr["username"]}
                    td.text-center #{rowArr["state"]}
                    td.text-center #{rowArr["stage"]}
                    td.text-center Not Implemented Yet
block scripts
    script(src='/js/pages/datatable.js')

It does seem to consistently load an entire row each time it begins a row.

Are you waiting for all the threads to finish? You mention you run 5 queries, but I only see you waiting for one.
The order in which they all terminate is not going to be deterministic, you must wait for each of them to finish before you try to use it's data.
The fact that sometimes it works could be when this last one terminates after all the others.

Alternatively, it could also mean that the MsSQL driver is not thread safe, though I have no idea if that is the case or not, but I guess it's fairly unlikely.

Also, I think it's generally a bad idea to mix std.parallelism with vibe.d. Vibe's has it's own versions of most of std.parallelism, which will not block the event loop thread on contention, and will generally do the right thing.
The major difference is that for example in your case, when you call yieldForce(), vibe.d cannot just go and do something else, like handle another request. The OS will just switch away from your event loop thread altogether. This is very inefficient and goes against vibe'd async model.