[M3devel] new unknown qualification errors

[Tony Hosking]

On Jan 28, 2008, at 8:30 AM, Neels Janosch Hofmeyr wrote:

> Thanks Daniel, that seems to work.
>
> However, if SchedulerPosix does not support these calls  
> (DisableSwitching and EnableSwitching), do we not end up with  
> concurreny problems? (This assuming that the Scheduler internally  
> calls SchedulerPosix on POSIX platforms, which I am just wildly  
> guessing...)

The calls to Schedule.DisableSwitching/EnableSwitching turn into  
different things for different threading subsystems.  The reason is  
because SIGVTALRM-based thread scheduling (ThreadPosix) can cause  
thread switches in library code that is not thread-safe.  Thus,  
certain system calls need to be wrapped in DisableSwitching/ 
EnableSwitching calls which prevent user-level threads switches.   
With system thread scheduling (ThreadPThread) the library calls are  
known to be thread-safe (since we link with a pthreads-aware C  
library) so DisableSwitching/EnableSwitching can be implemented as a  
no-op.  The purpose of this is to allow suplib (and CVSup) to be  
compiled for all POSIX targets (both pthreads and user-threads).

So, short answer to your question is: no, we don't end up with  
concurrency problems.

>
> Thanks again,
> Neels
>
> Daniel Alejandro Benavides D. wrote:
>> Hi Neels:
>> If I rememeber this happen since some time ago. Just look this  
>> post of mine, you need to change the IMPORT and the lines that  
>> compiler complains:
>> https://mail.elegosoft.com/pipermail/m3devel/2008-January/ 
>> 000806.html:
>> importing Scheduler instead of SchedulerPosix Then replace the  
>> call for the functions of SchedulerPosix for Scheduler
>> I think that would solve that problem.
>>
>> Thanks,
>>
>> Daniel Benavides
>>
>>
>>
>>
>> */Neels Janosch Hofmeyr <neels at elego.de>/* escribió:
>>
>>     Hi devel,
>>
>>     I am trying to compile the suplib with the new 5.5.1 snapshot  
>> cm3. It
>>     worked fine with 5.4.0, but now I get errors I cannot figure out
>>     how to
>>     correct:
>>
>>     ===> suplib
>>     --- building in LINUXLIBC6 ---
>>
>>     new source -> compiling StatBufOffT64.m3
>>     "../src/StatBufOffT64.m3", line 40: unknown qualification  
>> '.' (asLong)
>>     "../src/StatBufOffT64.m3", line 45: unknown qualification '.'
>>     (assignOffT)
>>     2 errors encountered
>>     new source -> compiling Ugzip.m3
>>     "../src/Ugzip.m3", line 63: unknown qualification '.'
>>     (DisableSwitching)
>>     "../src/Ugzip.m3", line 67: unknown qualification '.'
>>     (EnableSwitching)
>>     "../src/Ugzip.m3", line 74: unknown qualification '.'
>>     (DisableSwitching)
>>     "../src/Ugzip.m3", line 78: unknown qualification '.'
>>     (EnableSwitching)
>>     4 errors encountered
>>     new source -> compiling CVTree.m3
>>     "../src/CVTree.m3", line 315: unknown qualification '.'
>>     (DisableSwitching)
>>     "../src/CVTree.m3", line 319: unknown qualification '.'
>>     (EnableSwitching)
>>     "../src/CVTree.m3", line 325: unknown qualification '.'
>>     (DisableSwitching)
>>     "../src/CVTree.m3", line 329: unknown qualification '.'
>>     (EnableSwitching)
>>     "../src/CVTree.m3", line 335: unknown qualification '.'
>>     (DisableSwitching)
>>     "../src/CVTree.m3", line 339: unknown qualification '.'
>>     (EnableSwitching)
>>     6 errors encountered
>>     compilation failed => not building library "libsuplib.a"
>>     Fatal Error: package build failed
>>
>>
>>     I need help with all of these. However, I tried investigating the
>>     first
>>     one: Utypes.asLong()
>>
>>     By coincidence, I saw that in FSPosix.m3, a line saying
>>     status.size := Utypes.asLong(statBuf.st_size);
>>     was changed to
>>     status.size := ORD(statBuf.st_size);
>>
>>     Reading the log for the linux/Utypes.i3 gets me confused. It says
>>     how to
>>     make a off_t from a long, but doesn't say anything about the  
>> reverse
>>     direction. Is ORD(x) always the way to go? Here is the log  
>> extract:
>>
>>     revision 1.4
>>     date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp;  
>> lines:
>>     +0 -3; commitid: 3xU0vDzVxflBSpHs;
>>     Remove residual implementations of Utypes.asLong and
>>     Utypes.assignOffT.
>>     ----------------------------
>>     revision 1.3
>>     date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp;  
>> lines:
>>     +1 -0;
>>     add a procedure to assign values to off_t variables, as they may
>>     now be
>>     structured types, depending on the platform:
>>
>>     PROCEDURE expandAssign(VAR dest: off_t; src: long)
>>
>>
>>     Well, where would API changes like these be documented, if I ever
>>     need
>>     to look them up on my own?
>>     Thanks,
>>
>>     --     Neels Janosch Hofmeyr
>>     Software Developer
>>
>>     neels at elego.de
>>     Public Key: http://binarchy.net/neels/ 
>> neels.hofmeyr.public.key.asc
>>
>>     elego Software Solutions GmbH http://www.elegosoft.com
>>     Gustav-Meyer-Allee 25, Gebäude 12 HRB 77719
>>     13355 Berlin, Germany Amtsgericht Charlottenburg
>>     Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin
>>     Fax: +49 30 23 45 86 95 Geschäftsführer: Olaf Wagner
>>
>>
>>
>>
>> ¿Con Mascota por primera vez? - Sé un mejor Amigo
>> Entra en Yahoo! Respuestas <http://es.rd.yahoo.com/evt:51361/ 
>> *http://es.answers.yahoo.com/dir/ 
>> index;_ylc=X3oDMTE4ZWhyZjU0BF9TAzIxMTQ3MTQzMjIEc2VjA0Jhbm5lcgRzbGsDQW 
>> NxdWlzaXRpb24-?link=over&sid=XXXXXXXX>.
>
> -- 
> Neels Janosch Hofmeyr
> Software Developer
>
> neels at elego.de
> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc
>
> elego Software Solutions GmbH           http://www.elegosoft.com
> Gustav-Meyer-Allee 25, Gebäude 12       HRB 77719
> 13355 Berlin, Germany                   Amtsgericht Charlottenburg
> Tel.: +49 30 23 45 86 96                Sitz der Gesellschaft: Berlin
> Fax:  +49 30 23 45 86 95                Geschäftsführer: Olaf Wagner
>
>