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>
Project Administrator
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.4