Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: uThreads – Concurrent User Threads in C and C++

samanbarghi.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#41

Post by striking »

jimktrains2 wrote: post #18
jtsylve wrote: post #13

Is there any reason you chose GPL3 or would you consider a less restrictive license like Apache or BSD?

Is there a reason you'd choose Apache or BSD instead of a freedom preserving license like GPL3?

Licensing GPL software can be a nightmare. Using Apache, BSD, MIT, LGPL means I don't have to give licensing a second thought.

And speaking as someone who writes software for a non-profit, we figure we should just give away the code we write rather than put our own political license on it, especially considering we don't pay taxes in order to make it easier for us to benefit "the people".

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#42

Post by striking »

aseipp wrote: post #21
jimktrains2 wrote: post #18

Earlier quoted context omitted.

Is there a reason you'd choose Apache or BSD instead of a freedom preserving license like GPL3?

They probably want to use it, make money off it, and give nothing back to anyone. The same as most people who complain about it, IMO. Or, just as likely, they'll integrate it into their own BSD software, which will then be used by someone else to make money, and give nothing back, which might as well be the same thing. (Countdown until 1 person shows up and retorts "Well, my company supports the OSS we use..." as if…

It's harder for me to agree with a library being licensed under GPL than if it were an entire application being licensed under GPL.

If someone's licensing an entire application that's usable in its own right, like an SQL server or emulator or game or kernel, then it totally makes sense that anything you build around it should have its code be accessible.

But if it's some smaller part of your entire codebase, I feel it's a little less reasonable for people who aren't working on something that's already *GPL licensed. Especially when you have middlewares or other proprietary pieces of code linked with yours. That, plainly and simply, will prevent you from using the library. (Except if it's the LGPL, which I've never had problems with. I personally like it the most, and I'd use it if I really cared about people upstreaming their changes.)

I'm not going to say "this library is bad because it's GPL'd" but it does mean I would avoid baking it into a programming language runtime, for example.

And it really bothers me that you have such a low opinion of people who comment here, and of people who disagree with you. Maybe it's just an exaggeration for argument's sake, but I feel like there are plenty of reasonable arguments against use of the GPL.

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#43

Post by naasking »

saman_b wrote: post #36
naasking wrote: post #25

Why not just use StateThreads? A comparison against other options would be illuminating.

Good idea, I probably write a blog post on this later. If you take a look at [1], I explain the difference between N:1 and M:N mappings. StateThreads uses a N:1 mapping which means you can multiplex many fibers over a single thread and to take advantage of multi-processors you can have M processes that do N:1 mapping, which is a common practice (libmill, libdill, ...). But with uThreads you can multiplex many fibers…

Sure, I get the M:N argument, but that wasn't something you could extend existing solutions to support?

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#44

Post by saman_b »

naasking wrote: post #43
saman_b wrote: post #36

Earlier quoted context omitted.

Good idea, I probably write a blog post on this later. If you take a look at [1], I explain the difference between N:1 and M:N mappings. StateThreads uses a N:1 mapping which means you can multiplex many fibers over a single thread and to take advantage of multi-processors you can have M processes that do N:1 mapping, which is a common practice (libmill, libdill, ...). But with uThreads you can multiplex many fibers…

Sure, I get the M:N argument, but that wasn't something you could extend existing solutions to support?

Do you have anything specific in mind? The only code I found similar to this is uC++ [1], which has way more features and more sophisticated scheduler. I am using this as part of my research and wanted to have sth very simple.

For all N:1 mappings, since there is only a single process, there is no need for synchronization, also there is no need for any scheduler as a simple queue suffice. But as soon as multiple threads are introduced, there is a need for orchestration among threads and it also changes all other aspects of the code. Of course, I could develop on top of an existing codebase, but I suspect I had to change so much that it is better to start from scratch anyway.

------------------------------------

[1]https://plg.uwaterloo.ca/usystem/uC++.html

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#45

Post by saman_b »

michaelsbradley wrote: post #35
saman_b wrote: post #32

Earlier quoted context omitted.

In libdill approach, you are probably limited to only multiplex connections over multiple kernel threads. And when a connection is accepted over a kernel thread it has to perform all further instructions over that kernel thread. So it gives you a bit of control over which cores to be utilized but after that you do not have control over what part of the code should be executed on each core. Using uThreads you can deci…

First time I've heard of SEDA, though I've been aware of the concerns/concepts it addresses, in various forms, for some time. Any thoughts on Welsh's Retrospective on SEDA ? http://matt-welsh.blogspot.com/2010/07/retrospective-on-seda...

I have seen this before. Those are very good points, and I am trying to move this library towards supporting a SEDA type architecture with dynamic control and auto tuning runtime parameters.

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#47

Post by edvinbesic »

tomjakubowski wrote: post #38
CyberDildonics wrote: post #34

Earlier quoted context omitted.

Yes, using green threads for ray tracing is basically nonsense, since keeping actual threads busy is no overly difficult.

It's not nonsense if, to render each pixel, you issue an HTTP request containing the scene/eye data and requested pixel coordinate, and wait for a response to come back from your magic render farm that lives in "the cloud". Now your "ray tracer" is totally I/O bound! :-)

Not sure if /s, but, to rasterize a 1920x1080 image you would make 2073600 HTTP requests? Sound reasonable.

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#48

Post by naasking »

saman_b wrote: post #44
naasking wrote: post #43

Earlier quoted context omitted.

Sure, I get the M:N argument, but that wasn't something you could extend existing solutions to support?

Do you have anything specific in mind? The only code I found similar to this is uC++ [1], which has way more features and more sophisticated scheduler. I am using this as part of my research and wanted to have sth very simple. For all N:1 mappings, since there is only a single process, there is no need for synchronization, also there is no need for any scheduler as a simple queue suffice. But as soon as multiple thre…

> For all N:1 mappings, since there is only a single process, there is no need for synchronization, also there is no need for any scheduler as a simple queue suffice.

Wouldn't an M:N model simply amount to work stealing among N kernel-thread-local queues? This seems like it should be a pretty straightforward extension to one of the user-level C thread packages.

Or are you doing something more elaborate for your research?

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#49

Post by jcbeard »

How would something like this differ from something like Sandia National Lab's Qthreads (http://www.cs.sandia.gov/qthreads/)? Seems it's a tried and true solution in C that also works with C++11 (committed a test case for C++11 myself)...It is also an optional underpinning for some relatively big-name frameworks like Kokkos, Chapel, RaftLib, etc.

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#50

Post by saman_b »

purple-dragon wrote: post #46

I've had success with Intel's Threading Building Blocks. Is there a reason I might prefer something like this instead?

Seems like a very mature library, I can't answer your question before I go through their documentation and code. Also, I find your question a bit abstract, since I am not aware of the details of the problem you are trying to solve, I cannot reason why any library or tool can be better over other libraries. In your case, TBB might fit your requirements and it might be hard to give a reason to switch to another library.
Post reply on HN