I don't think it is the right way either, but I was trying to confine the changes to as small an area as possible, just one file, to see if it still works, and some of the performance implications.
I completely agree with you, but from the benchmarks, the UMS replacement does appear to convince libuv that it is a real thread, not a scheduler with little threads inside. I will try to move the changes to replace the thread pool implementation instead of individual threads. Something that I think might be really interesting is if not just the workers were UMS threads, but the thread(s) that generates the requests and runs the callbacks was also UMS. Then, it could generate the requests, with UmsThreadYield for implicit synchronization, and use UmsThreadYield in the polling loop to check for and run call backs. But, I have read all of the documentation, and thoroughly looked over the source, and I see no real way to do that without massive external interface changes, other than suspending the thread, and swapping the Thread Environment Blocks. I might try that. My goal is to have no interface changes, just implementation changes, if they improve something. On Wed, Jul 1, 2015 at 2:14 AM, Saúl Ibarra Corretgé <[email protected]> wrote: > On 30/06/15 01:50, [email protected] wrote: > >> I successfully added UMS to libuv, it works. See commit >> >> https://github.com/codepilot/libuv/commit/facca7bbd9c40e90199470179d993915dd159341 >> >> The speed isn't too much slower, see fs_stat.txt >> <https://github.com/codepilot/libuv/blob/libuv/ums/test/fs_stat.txt> vs >> fs_stat_ums.txt >> <https://github.com/codepilot/libuv/blob/libuv/ums/test/fs_stat_ums.txt> >> >> The speed difference is mostly because UMS has some builtin >> synchronization, and so does the work queue. These conflict some, but do >> not cause errors, just slow downs. >> >> > Great work, thanks for sharing! > > IMHO, this is not the right way to integrate support for UMS, though it's > a great way to see it working. > > I think uv_thread_create should always use native threads. Then Windows > could use a threadpool implementation which uses UMS threads instead of > native threads. Doing this you might be able to simplify synchronization > and thus get some speedups. > > > Cheers, > > -- > Saúl Ibarra Corretgé > http://bettercallsaghul.com > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "libuv" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/libuv/DLXZdgwnt1k/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/libuv. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
