[M3devel] pthread/Interix

Tony Hosking hosking at cs.purdue.edu
Wed Dec 16 17:40:56 CET 2009


I really dislike this... just for a broken platform...

Is there really no way to know that the context on is not on the stack somewhere?

On 16 Dec 2009, at 10:36, Jay K wrote:

> [again, expect a bounce, but the mail does get through]
>  
>  
> Tony, for Interix, suspend/resume thread can be achieved writing to a file.
> Getting a suspended thread's registers can be gotten reading from a file.
> (I believe the same thing works on Solaris.)
> It appears to be intended for debuggers.
> I can see that it works well.
> I doubt that a thread's context is on a signal handler's stack.
> I propose:
>  
>  
>   ActState = { Starting, Started, Stopping, Stopped };
>   REVEAL Activation = UNTRACED BRANDED REF RECORD
>     frame: ADDRESS := NIL;              (* exception handling support *)
>     handle: pthread_t := NIL;           (* LL = activeMu; thread handle *)
>     statusFile: int := -1;              (* for Interix *)
>     controlFile: int := -1;             (* for Interix *)
>     (* C code knows the structure above this point *)
> ...
>   END;
> 
>  
> ThreadPThread.h:
>  
>  
> typedef struct _Activation_t {
>     void* frame;
>     void* pthread;
>     int statusFile;  /* for Interix */
>     int controlFile; /* for Interix */
> } Activation_t;
> 
>  
> and then whereever we pass act.handle off to C code, pass act instead.
>  
>  
> frame is kept first so that it is offset 0 in case that gives codegen efficiencies
> on the often used push/popframe.
> The other three are moved up to the top to reduce maintainence of ThreadPThread.h.
>  
>  
> I assume "branding" doesn't introduce data in the record.
> I'd have to check the codegen to verify frame is at offset 0.
>  
>  
> #ifdef code will open the files.
> Modula-3 code can check if the files are >= 0 and close them,
> or it can be a call out to #ifdefed C.
>  
>  
> An alternative is that wherever we pass act.handle, also pass act.statusFile and act.controlFile.
> (as VAR for initialization).
> That is less fragile and less extensible.
> I'm fine with that approach too.
>  
>  
> As well though, I was wondering, maybe we should have:
>  
>  
> common/InterixThreadState.i3
>  T = RECORD END; (* zero size? *)
>  
>  
> interix/InterixThreadState.i3
>   T = RECORD statusFile, controlFile := -1; END;
>  
>  
> and then put InterixThreadState.T in Activation.
> That way saving the other platforms from spending the space.
>  Just two integers, not much, but in principle..
>  (We also sometimes use up 8 bytes for the pthread_t when 4 would suffice,
>   on 64bit platforms with pthread_t == int, I think HP-UX is like that at least.)
>  
>  
> I could also open/close the files for every suspend/resume/processStopped,
> though that seems too lame.
>  
>  
> Another idea, that I don't really like, is to never optimize and
> ignore the registers and just use the stack.
> I rarely optimize, but depending on that seems bad.
>  
>  
> Your "safe points" proposal would also make this work, though
> I'd rather not wait for that.
>  
>  
> ?
>  
> Ok to add the two integers all the time?
> Ok to either depend on the record layout in C, or to always pass the integers around?
>  
>  
> Thanks,
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091216/deb17b9d/attachment-0002.html>


More information about the M3devel mailing list