3 ms·

In practical terms what happens is that your clients need to have a real good mental model of what will block and what won't. Also it turns out event driven pr

In practical terms what happens is that your clients need to have a real good mental model of what will block and what won't. Also it turns out event driven programming is fine when you do it, but wait 'till you have curl handles and say mysql handles and blah 'andles and foo andles. Fork andles! Threading sucks. Mixing event loops also really sucks. The developer centric way of doing it (e.g. screw performance I just want it to be correct and look nice) is really to flip to message passing and separate "logical processes". That's our unfortunate state of the art. EDIT: I didn't mention that I think all the userland threading libs I know of are crap. Which ones do you think are good? P.S I'm not going to be sarcastic or critical about it, I would really like to have portable, usable LWP in C or C++.

papsosouid 14y ago
>In practical terms what happens is that your clients need to have a real good mental model of what will block and what won't. I don't understand. Who are "clients" in this context? You need to know what calls will block and what calls won't regardless of style (event vs thread) unless you are using OS threads or processes. >Threading sucks. Why? >Which ones do you think are good? The one that comes with ghc.
- xyzzy123 14y ago
  I think perhaps the communications problem here is a difference in context. I'm coming from a C/C++ background. I get some Haskell but you'll have to explain specifics to me (I'm certainly willing to change my mind!). Are you using a framework, or developing one? Who gets to choose the concurrency strategy? As a framework provider, if you provide LWPs to ppl (like provide open and read and all that stuff for them) so they can write sequential code as if it were sequential, but it's actually nonblock, what happens in C/C++ is that when they need to integrate third-party stuff, life gets really complicated. Clients are the clients of the API I'm talking about, which is a hypothetical "lightweight thread" based API where everything just works as per original post. >>Threading sucks. >Why? Well, in an ideal model of computation we wouldn't need to synchronise things. This is the great attraction of likesay a node-based model where we run our stuff as synchronous events. Once you accept threading you need to care about who does what to which at what time. Also you need to figure out e.g. how your dependencies are thread-safe and under what conditions. You might have berkeley db where contexts are not generally thread-safe but handles can be if you set the right flags, for example. >>Which ones do you think are good? >The one that comes with ghc. That's cool :) I should probably learn more about it. The really cynical part of my mind is going "please tell me about this magical solution to integrating different event loops and concurrency models" and the less cynical part is open to your suggestions.
  - papsosouid 14y ago
    >Are you using a framework, or developing one? No. >Who gets to choose the concurrency strategy? The person writing code? >Clients are the clients of the API I'm talking about, which is a hypothetical "lightweight thread" based API where everything just works as per original post. In that context, I am the client. Here's how it works: forkIO myFunction That's it. Very simple, scales to millions of "threads", and if compiled with -threaded, those millions of "threads" are spread over a set of OS threads so I also get parallelism. >The really cynical part of my mind is going "please tell me about this magical solution to integrating different event loops and concurrency models" and the less cynical part is open to your suggestions. The key is just in the "demanding better from languages" part. You don't have to worry about a dozen incompatible green thread libraries if it is built into the language.
rdtsc 14y ago
Both suck, but I'll take threading (acutally I'll take Erlang's processes the most) but if I had to choose between the two, I'll take threads. > but wait 'till you have curl handles and say mysql handles and blah 'andles and foo andles. Fork andles! Yup. If I have an event driven program can I use another library that is not built on the same event driven framework? The answer is usually no. Even if it has the nice internally composible "futures/deferreds" feature. An operation that is non-blocking will return some kind of a future/promise/deferred thingy. Those bubble all the way to the top through the API. It means you need to have 3rd party libraries and support code that knows about them. This is the case with Twisted (which is a nice framework) but it means having to have a parallel universe of libraries for everything (because they have to return deferreds or being able to be passed in deferreds).
- xyzzy123 14y ago
  Thanks. I vigorously agree with you. I really wish I had a better way to explain it to people who haven't been screwed by it yet.
- papsosouid 14y ago
  >Yup. If I have an event driven program can I use another library that is not built on the same event driven framework? This is why my original post suggested that people need to start demanding better of their languages. This is a total non-issue in haskell because the "event driven framework" (that's really over-stating it, they are just relatively simple libs) is part of the language runtime. So everything uses it. I get concurrency and parallelism with the scalability of an event loop just by doing: forkIO myFunction

papsosouid 14y ago

>In practical terms what happens is that your clients need to have a real good mental model of what will block and what won't. I don't understand. Who are "clients" in this context? You need to know what calls will block and what calls won't regardless of style (event vs thread) unless you are using OS threads or processes. >Threading sucks. Why? >Which ones do you think are good? The one that comes with ghc.

xyzzy123 14y ago
I think perhaps the communications problem here is a difference in context. I'm coming from a C/C++ background. I get some Haskell but you'll have to explain specifics to me (I'm certainly willing to change my mind!). Are you using a framework, or developing one? Who gets to choose the concurrency strategy? As a framework provider, if you provide LWPs to ppl (like provide open and read and all that stuff for them) so they can write sequential code as if it were sequential, but it's actually nonblock, what happens in C/C++ is that when they need to integrate third-party stuff, life gets really complicated. Clients are the clients of the API I'm talking about, which is a hypothetical "lightweight thread" based API where everything just works as per original post. >>Threading sucks. >Why? Well, in an ideal model of computation we wouldn't need to synchronise things. This is the great attraction of likesay a node-based model where we run our stuff as synchronous events. Once you accept threading you need to care about who does what to which at what time. Also you need to figure out e.g. how your dependencies are thread-safe and under what conditions. You might have berkeley db where contexts are not generally thread-safe but handles can be if you set the right flags, for example. >>Which ones do you think are good? >The one that comes with ghc. That's cool :) I should probably learn more about it. The really cynical part of my mind is going "please tell me about this magical solution to integrating different event loops and concurrency models" and the less cynical part is open to your suggestions.
- papsosouid 14y ago
  >Are you using a framework, or developing one? No. >Who gets to choose the concurrency strategy? The person writing code? >Clients are the clients of the API I'm talking about, which is a hypothetical "lightweight thread" based API where everything just works as per original post. In that context, I am the client. Here's how it works: forkIO myFunction That's it. Very simple, scales to millions of "threads", and if compiled with -threaded, those millions of "threads" are spread over a set of OS threads so I also get parallelism. >The really cynical part of my mind is going "please tell me about this magical solution to integrating different event loops and concurrency models" and the less cynical part is open to your suggestions. The key is just in the "demanding better from languages" part. You don't have to worry about a dozen incompatible green thread libraries if it is built into the language.

rdtsc 14y ago

Both suck, but I'll take threading (acutally I'll take Erlang's processes the most) but if I had to choose between the two, I'll take threads. > but wait 'till you have curl handles and say mysql handles and blah 'andles and foo andles. Fork andles! Yup. If I have an event driven program can I use another library that is not built on the same event driven framework? The answer is usually no. Even if it has the nice internally composible "futures/deferreds" feature. An operation that is non-blocking will return some kind of a future/promise/deferred thingy. Those bubble all the way to the top through the API. It means you need to have 3rd party libraries and support code that knows about them. This is the case with Twisted (which is a nice framework) but it means having to have a parallel universe of libraries for everything (because they have to return deferreds or being able to be passed in deferreds).

xyzzy123 14y ago
Thanks. I vigorously agree with you. I really wish I had a better way to explain it to people who haven't been screwed by it yet.
papsosouid 14y ago
>Yup. If I have an event driven program can I use another library that is not built on the same event driven framework? This is why my original post suggested that people need to start demanding better of their languages. This is a total non-issue in haskell because the "event driven framework" (that's really over-stating it, they are just relatively simple libs) is part of the language runtime. So everything uses it. I get concurrency and parallelism with the scalability of an event loop just by doing: forkIO myFunction