CreateNewProc bug in SASC ?

[Piru]

Your bug: stdio is not thread safe.

[Piru]

@ChaosLord

printf() works inside Forbid() just fine (tho it is bad style IMO). Forbid() is broken when needed.

Permit() is not needed at the end of a subprocess. In fact, it's often useful to avoid the parent being allowed to run before the subprocess has terminated.

The real problem is that stdio is not thread safe.

[Piru]

@ChaosLord

Can a regular Process with no children or parents, do a Forbid() without Permit() near the end?

For example a CLI command?

No.

Well it can, but that is a bug (the CLI will then inherit the pending Forbid, and it will cause all sorts of nasty things).

[Piru]

@Georg

If you are lucky enough not to be screwed by the process cleanup routines if the they do something which calls Wait() and breaks Forbid() state.

Screwed how? The execution is inside the OS now, and will not return to the seglist, so the seglist can disappear as soon as the final 'rts' has executed.

The Forbid() is there only to ensure that the final couple of instructions (typically poking some flag or calling ReplyMsg()) can execute without the seglist being unloaded under it.

[Piru]

@Thomas

Good point. That is the reason for outright crash.

However, even with __saveds it won't be safe... Neither SAS/C stdio, nor dos.library buffered I/O is thread safe.

[Piru]

Is stdio "Resident safe"?

By default it isn't.

How to create a residentable (or pure) application depends on the compiler. For example one SAS/C you link against LIB:cres.o. With gcc you use -resident switch (should work with ixemul at least). I'm not familiar with VBCC.

This applies to c-library stdio. If you use dos.library stuff and keep all variables local then these restrictions do not apply, obviously. That way it's possible to do pure applications even without any startup or stdlib code, for example.

[Piru]

@Jose

As for stdio not being thread safe. I've debugged various multithreaded functions in the past and worst result I've had AFAIremember was the text output being mixed up, but no crashes.

It can crash, it's just not very likely to happen.

However, in my personal opinion nothing is more annoying than rare, untrackable crashes.

[Piru]

Try with this code, it certainly work better.

Actually it doesn't. dos.library buffered I/O isn't thread safe (that is, you cannot safely access buffered filehandle from multiple processes). The filehandle buffer isn't protected against simultanous access, so if you're unlucky things can go badly wrong.

If you print just couple of lines it's not very likely to break, however.