------=_Part_42671_22351429.1155400466800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

All,

David cam up with a solution that looks to me as some thing that would be
really nice, he suggested that OpenSSL would allow the developer to register
a callback function to do the unsafe functions.

However while he thinks OpenSSL should default to the OS 'best' function
available, I am not sure, could be that it still could be good to have at
least the OpenSSL functions clean with mutex.

Q. What do we (Me or some one else) needs to do to get this callback
function thing rolling into the CVS?

Joe

On 8/12/06, Stefan.Neis@t-online.de wrote:
>
> Hi,
>
> > >why not use mutexes to wrap the gmtime and memcpy,
> > >like other places in the library?

> >
> > Because it is either needless or insufficient.

> (snipp)
> > On platforms where thread-specific
> > data is not used, the mutexes would not prevent other code (not part of
> > OpenSSL) from calling these functions in-between when OpenSSL calls them

> and
> > when the returned data can be used or copied.

>
> Well, while it is still insufficient, mutexes would allow a user calling
> OpenSSL functions from multiple threads to do so without having to worry
> about
> all the internals, like "do function a() and b() both use gmtime
> internally,
> so a common mutex around those two function calls is needed?" Not to
> mention
> that in a cross-platform application it's going to be needed on a few
> platforms
> only, while on most it will work without them. Ensures interesting testing
> and
> debugging sessions, IMO.
> Of course, if the user is calling gmtime himself, he still needs to know
> such
> stuff, but that might be less common than calling two openssl functions
> that
> end up calling gmtime. Also, you could add a warning in such case that any
> multi-threaded application needs to wrap their gmtime calls with such and
> such
> mutex.
>
> OTOH, if you have two or more libraries taking this approach, each using a
> gmtime wrapper with its own mutex, that's possibly going to be more
> confusing
> than helpful.
>
> Regards,
> Stefan
>
>
>
>
> __________________________________________________ ____________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List openssl-dev@openssl.org
> Automated List Manager majordomo@openssl.org
>


------=_Part_42671_22351429.1155400466800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

All,

 

David cam up with a solution that looks to me as some thing that would be really nice, he suggested that OpenSSL would allow the developer to register a callback function to do the unsafe functions.

 

However while he thinks OpenSSL should default to the OS 'best' function available, I am not sure, could be that it still could be good to have at least the OpenSSL functions clean with mutex.

 

Q. What do we (Me or some one else) needs to do to get this callback function thing rolling into the CVS?

 

Joe

 

On 8/12/06, Stefan.Neis@t-online.de <Stefan.Neis@t-online.de> wrote:

       Hi,

> >why not use mutexes to wrap the gmtime and memcpy,
> >like other places in the library?

>
>       Because it is either needless or insufficient.
(snipp)
> On platforms where thread-specific
> data is not used, the mutexes would not prevent other code (not part of
> OpenSSL) from calling these functions in-between when OpenSSL calls them and

> when the returned data can be used or copied.

Well, while it is still insufficient, mutexes would allow a user calling
OpenSSL functions from multiple threads to do so without having to worry about
all the internals, like "do function a() and b() both use gmtime internally,

so a common mutex around those two function calls is needed?" Not to mention
that in a cross-platform application it's going to be needed on a few platforms
only, while on most it will work without them. Ensures interesting testing and

debugging sessions, IMO.
Of course, if the user is calling gmtime himself, he still needs to know such
stuff, but that might be less common than calling two openssl functions that
end up calling gmtime. Also, you could add a warning in such case that any

multi-threaded application needs to wrap their gmtime calls with such and such
mutex.

OTOH, if you have two or more libraries taking this approach, each using a
gmtime wrapper with its own mutex, that's possibly going to be more confusing

than helpful.

       Regards,
               Stefan




__________________________________________________ ____________________
OpenSSL Project                                
http://www.openssl.org

Development Mailing List                       penssl-dev@openssl.org">openssl-dev@openssl.org
Automated List Manager                          
majordomo@openssl.org



------=_Part_42671_22351429.1155400466800--
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org