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

Submitter:  Raphael Mack <ramack>
Submitted:  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:  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?

Zwakenberg <hzwakenberg>
Project Member
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 Administrator
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


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

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)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.




    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.9