Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Projjal Gupta
    @paltrickontpb
    Alright thank you! I called I2C in main script again after including in library
    Maged Ahmed Rifaat
    @magedrifaat
    Congratulations 李井瑞!
    李井瑞
    @JingruiLea
    Thanks a lot! I'll do my best on this project.
    tyrbentsen
    @tyrbentsen
    Hi all, it seems like the synchronous programming model is very valuable and useful. So I was wondering why we don't see it more often in other languages that are now mainstream? E.g. language constructs like par/or and par/and seem like are a great, easy way to make parallel compositions and do synchronization, etc... Why don't we see such constructs in newer languages like Rust or Go that also have some focus on safe concurrency?
    Daniel Austin
    @fluffynukeit
    I think we do see them in Go, but they have a different flavor compared to Ceu. In Ceu, the semantics for rejoining trails is baked into the language keyword (and vs or), and as a result you don't have a complex await statement, but simple await statements in several parallel trails. In Go, the complexity for launching a "trail" is easy using the go keyword, but the complexity is pushed back into the awaiting condition.
    You could have similar semantics in Ceu as you would in Go if this sort of thing were possible. I'm not sure it is presently, and I might be getting the syntax wrong because I'm by no means proficient in Ceu:
    var a = spawn Trail1; var b = spawn Trail2; await a or b
    tyrbentsen
    @tyrbentsen
    but that's asynchronous no? (I haven't done any programming in Go)
    Daniel Austin
    @fluffynukeit
    yes it is asynchronous. I thought the crux of your question regarded parallel comp and synchronization between parallel constructs, not strictly the synchronous programming model.
    to me I don't see much distinction between a synchronous model and an asynchronous one that has methods to impose synchronization when you need it. The synchronous model is arguably simpler and easier to get right, if that's the "very valuable" part you mean
    Francisco Sant'Anna
    @fsantanna

    Hi all, it seems like the synchronous programming model is very valuable and useful. So I was wondering why we don't see it more often in other languages that are now mainstream? E.g. language constructs like par/or and par/and seem like are a great, easy way to make parallel compositions and do synchronization, etc... Why don't we see such constructs in newer languages like Rust or Go that also have some focus on safe concurrency?

    Some languages have co-routines which are somewhat "compatible" with the synchronous model.
    However, to support syntactic parallel compositions, the language really has to embrace and compromise with the execution model, which would affect the whole design of the language.
    In particular, the "par/or" is tricky since it must abort another unaware line of execution immediately.
    I like this paper discussing immediate/orthogonal abortion: https://link.springer.com/chapter/10.1007%2F3-540-57529-4_44
    So, I believe it's too risky and the tradeoffs are not yet fully understood.
    These languages tend to have half solutions with "async/await" and similar alternatives.
    I also think people in the academia still see the synchronous model as somewhat disingenuous, regradless of all research done.
    Another reason is the growth of functional languages which affected research in synchronous languages towards functional reactive programming.

    Francisco Sant'Anna
    @fsantanna

    to me I don't see much distinction between a synchronous model and an asynchronous one that has methods to impose synchronization when you need it. The synchronous model is arguably simpler and easier to get right, if that's the "very valuable" part you mean

    I believe he's not talking about synchronous/asynchronous call, but actually about their execution semantics (synchronous scheduling) after they start/while they execute (with deterministic preemption, etc).

    Asynchronous dispatching is easy in Céu as you suggested. Although, we don't have the await a or b syntax, we do have the spawn to get a reference and then could do par/or do await a; with await b; end.

    Synchronous scheduling is what allows the par/or to be safe and brings all the nice features of Céu. That's also the compromise thing I mentioned and the reason why I think others do not embrace it.

    Francisco Sant'Anna
    @fsantanna
    Another reason is that the synchronous model hinders multi-core execution and the popular trend is on solutions that avoid sharing memory at all costs (Actors/Erlang/etc). I believe that's a mistake because many classes of applications cannot completely isolate their lines of execution either for "logical" reasons or cache locality, but that's only a claim.
    Daniel Austin
    @fluffynukeit
    could modifications to spawn and await roughly capture the par/or and par/and semantics? I suppose specifically, var a = spawn Trail1; var b = spawn Trail2; await a or b; Let spawn now be synchronous. Have a get priority because it is listed in the code first, like par/or trails. Allow await...or semantics so that the completion of a automatically kills b and vice versa. Do those changes effectively reproduce the existing par/or behavior?
    Francisco Sant'Anna
    @fsantanna

    Let spawn now be synchronous.

    Synchronous in which sense?

    var a = spawn Trail1; var b = spawn Trail2; await a or b;

    would be equivalent to

    var a = spawn Trail1; var b = spawn Trail2; par/or do await a; with await b; end

    which is equivalent to

    par/or do await Trail1; with await Trail2; end

    The first syntax existed in the past. The other two are valid now.

    Daniel Austin
    @fluffynukeit
    How recently was the final syntax form supported?
    Francisco Sant'Anna
    @fsantanna
    Probably since before spawn. When code/await was first introduced.
    Daniel Austin
    @fluffynukeit
    Is there something gained by having the par/or and par/and (the rejoining behavior) come first before, or "enclose" if you will, the creating of the trails? Does it help with scheduling or concurrency analysis, for instance? I admit the fake spawn/await example I put together feels more familiar to me because it's closer to how lots of languages do it, so I'm wondering what motivated par/or/and etc design choice, whether it be technical or your own personal preference
    Francisco Sant'Anna
    @fsantanna
    Because one can inline code there. If Trail1 and Trail2 are just called once, you don't need them and you may put their code directly there.
    Some trails are just one liners as well:
    par/or do
        await 1s;
    with
        await Trail2();
    end
    Some time you want to mix all of them together:
    par/or do
        await 1s;
    with
        await Trail1();
        await 500ms;
        await Trail2();
    end
    It's more flexible.
    Daniel Austin
    @fluffynukeit
    Thanks. I'll need to digest this a little more to really grok the advantages. At first glance, it's not obvious to me why those couldn't be accomplished via the fake syntax: await 1s or Trail2(), for example. However, I do think your second example would be more verbose if it had to be done with a
    var a = spawn do 
        await Trail1();
        <etc>
    end
    await 1s or a;
    Francisco Sant'Anna
    @fsantanna
    Ok, change 1-liners to 2-liners. You will need to give names to things that could be anonymous. Even for the await 1s or a, you loose the symmetry between the two.
    Daniel Austin
    @fluffynukeit

    You will need to give names to things that could be anonymous.

    Indeed, good point. Thanks

    tyrbentsen
    @tyrbentsen
    Thank you for the replies.
    After a quick read of the paper you mentioned: https://link.springer.com/chapter/10.1007%2F3-540-57529-4_44, I was wondering if abortion of asynchronous code is possible in Céu (e.g. await async/thread) or is it only possible for synchronous code?
    Francisco Sant'Anna
    @fsantanna

    I was wondering if abortion of asynchronous code is possible in Céu (e.g. await async/thread) or is it only possible for synchronous code?

    Yes, it is possible and supported.

    Asynchronous threads exist in Céu for two reasons:

    • To perform time-consuming computations
    • To interact with blocking I/O libraries
      Threads have independent scheduling and must live in a global structure in the heap (currently a linked list).
      When they need to share memory with the synchronous side , they must use an atomic block for mutual exclusion (e.g., to communicate the result of a computation or blocking input).
      Since they have independent scheduling, they cannot be aborted with perfect synchronization with the synchronous side.
      So, when a par/or wants to abort a nested thread, these are the possibilities:1. The thread is inside an atomic block. This is actually not a possibility since the synchronous side could not be executing (mutual exclusion).2. The thread is computing a value.3. The thread is blocked.
      The two last options are harmless for the synchronous side.So, when a par/or wants to abort a thread it does two things:- It calls an ABORT wrapper that, if supported by the underlying API (e.g. pthread_cancel), signals the thread that it should terminate. If not supported, the thread will just waste CPU cycles.
    • It sets an aborted flag in the global structure. In the generated code, when a thread tries to enter an atomic block, it first checks this flag to possibly terminate directly.
    tyrbentsen
    @tyrbentsen
    Thank you for the clarification!
    What happens if the async thread does IO after the par/or block has been aborted but before the thread has been terminated?
    So after the par/or block finishes but before the async thread reaches such an atomic block like you described or a pthread_cancel cancellation point.
    tyrbentsen
    @tyrbentsen
    E.g. a par/or block with one trail that awaits a button press, and another trail that writes a bunch of lines to a file (and checks every 10 lines for cancellation). What happens when the button is pressed, but before the 10th line is reached?
    Francisco Sant'Anna
    @fsantanna
    The I/O will occur. If it's a printf the user will see its message on the screen.
    I forgot to discuss problems related to leaks, but I believe it's already clear...
    In this same example, the thread will not reach fclose at its end, so it should resort to pthread's clean up mechanisms.
    Of course, the whole idea of Céu is to do I/O in the synchronous side. I/O in threads should be a "temporary hack" before finding/porting an appropriate asynchronous alternative (e.g., libuv).
    tyrbentsen
    @tyrbentsen
    That makes perfect sense!
    Thank you
    tyrbentsen
    @tyrbentsen
    Hi, I have another question. Why is it needed to emit external output events
    Why not doing the output directly?
    Francisco Sant'Anna
    @fsantanna
    • For symmetry with input, Céu is designed to model I/O so it's expected to provide both as special.
    • To aid static analysis. It is easy to track external side effects.
    • To link output and input events between different processes transparently, potentially in different machines. (See https://www.maxwell.vrac.puc-rio.br/37372/37372.PDF)
    If possible, I suggest to move this kind of discussion to the mailing list of Céu: https://groups.google.com/forum/#!forum/ceu-lang
    (Let's use the chat for more real-time interactions on installing/operating the language, etc.)
    tyrbentsen
    @tyrbentsen
    Thank you!
    Dinesh Bhagat
    @rapperdinesh
    Hi ! I am Dinesh Bhagat , a sophomore at IIT Mandi, India. I am interested in contributing in ceu language. Can anyone please guide me in the same ?
    Dinesh Bhagat
    @rapperdinesh
    While installing Ceu I am facinf difficulty in the below step. """sudo make install # install as "/usr/local/bin/ceu""". Please help !
    Francisco Sant'Anna
    @fsantanna
    Hi @rapperdinesh , what error do you get when you try it?
    Dinesh Bhagat
    @rapperdinesh
    @fsantanna It shows this message """install ./src/lua/ceu /usr/local/bin/ceu"""
    Francisco Sant'Anna
    @fsantanna
    Did you try to run the tests?
    Dinesh Bhagat
    @rapperdinesh
    on running test it shows this error --> https://pasteboard.co/IGOnulR.png
    and on make samples it shows --> make: * No rule to make target 'samples'. Stop.
    Francisco Sant'Anna
    @fsantanna
    In which directory are you running make samples?
    Dinesh Bhagat
    @rapperdinesh
    Thanks @fsantanna .... Got it, Solved the issue ! Thanks for the help ! Looking forward to contribute in the code base !