taskLiberty Eiffel - Tasks: task #13320, Make generated C code thread-safe


You are not allowed to post comments on this tracker with your current authentication level.

task #13320: Make generated C code thread-safe

Submitted by:  Raphael Mack <ramack>
Submitted on:  Wed 10 Sep 2014 08:01:46 PM UTC  
Should Start On:  Tue 09 Sep 2014 10:00:00 PM UTC Should be Finished on:  Tue 09 Sep 2014 10:00:00 PM UTC
Category:  SmartEiffel Priority:  5 - Normal
Status:  In Progress Percent Complete:  20%
Assigned to:  Cyril Adrian <cadrian> Open/Closed:  Open
Fixed Release:  None Planned Release:  None
Effort:  0.00

Fri 03 Jun 2016 11:52:22 AM UTC, comment #3: 

AFAIK Cyril used ømq for one of his projects.
We haven't put formal checks and tests, yet, I'm going to add them.
Just a suggestion, what approach do you suggest?

1. completely separate executables with their own makefile. Cleaner but harder to integrate into current automatic testing framework
2. forking server and client using PROCESS in cluster exec. Easier but client and server will share the same, common parent process.

Paolo Redaelli <Tybor>
Project Administrator
Mon 15 Feb 2016 11:21:43 AM UTC, comment #2: 

if IPC is the preferred alternative to threading, we'd need this to be non-blocking, indicating the additional need for a message queue library.  Can MQ0 be used for that?  Is the wrapping complete and validated?

Hans Zwakenberg <hzwakenberg>
Sun 14 Sep 2014 06:34:59 AM UTC, comment #1: 

WIP in commits 0f7dcbc, 97ea62c, 119d646, c369ded, and others.

Basic infrastructure in place (thread-local variables), loads of work still to do at least in the GC and plugins.

Cyril Adrian <cadrian>
Project AdministratorIn charge of this item.
Wed 10 Sep 2014 08:01:46 PM UTC, original submission:  

As a starting point, how about just making the generated C code thread-safe?  Right now the use of global static variables makes the generated C code unsafe.

But as soon as you say Thread, it is unsafe :-) [[User:Colnet|Colnet]] 17:06, 19 Dec 2005 (CET)

So basically it sounds like there is no plan for implementing SCOOP in a cross-platform-compatible way-- is that correct?

It is. SCOOP is fairly complex (conceptually), hence it is rather complex (to implement), therefore it is quite complex (to use). We are not sure about implementing SCOOP. But maybe thread safety can be achieved. There are not a lot of global variables and they are almost useless (I think in particular of <tt>se_dst</tt>). It means that
# even if we don't implement SCOOP, someone else would be able to;
# we won't provide a THREAD class, but a third party could do so once the code is thread safe (probably using [[Plugins]]);
# there is already some multi-tasking possibilities in SmartEiffel: cooperative multi-tasking implemented by the <tt>lib/sequencer</tt> cluster, with examples both in the tutorial and The Computer Language Shootout Benchmarks (look at the cheap concurrency and chameneos benchmarks);
# we'd rather implement communication between process: watch the <tt>lib/net</tt> cluster, it should evolve in the following months.
--[[User:Cadrian|Cyril]] 09:43, 21 Dec 2005 (CET)

Raphael Mack <ramack>
Project Administrator


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by Tybor (Posted a comment)
  • -email is unavailable- added by hzwakenberg (Posted a comment)
  • -email is unavailable- added by ramack (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-09-14 cadrian CategoryNone => SmartEiffel
        StatusNone => In Progress
        Percent Complete0% => 20%
        Assigned toNone => cadrian

    Back to the top

    Powered by Savane 3.6