[Lazarus] thread safe

[Martin]

On 27/06/2011 15:58, Hans-Peter Diettrich wrote:
> Martin schrieb:
>
>> See my example about memory alloc in my other mail. It shows, that a 
>> piece of code (and it's ability to be "safely invoked ") does not 
>> solely depend on the parameters passed, but also on (selected parts 
>> of) the state of the application or system.
>
> What when some code does not return anything, *and* cannot work at all 
> due to some problem (out-of-memory, file deleted, object destroyed...)?
>
> When e.g. a file search cannot proceed due to missing access rights? 
> It cannot return an boolean value (succ/fail), because it's simply 
> unknown whether the file exists.
>
> When in case of an unexpected error the called procedure throws an 
> exception? Can this procedure *ever* be "safely invoked", when it may 
> return to some other place in code (exception handler)?

Yes, why not. IF this is the defined behaviour. Exceptions can be 
caught. To safely call such a function one would need to define an 
exception handler. But it can be safely called.

That a function can be safely called does not mean that there is no way 
to call it unsafely.

A function expecting a pointer to some specific data, may be able to 
check if the pointer is nil, but it can not necessarily check if the 
pointer is otherwise valid.
Hence input range for which the function is defined, is a pointer that 
is nil, or pointing to the correct type of data. Within this range of 
input the function may be called and will be safe, with other input the 
result of calling the function is not defined, hence it is not safe.