EQ_EXPORTs on threading primitives

[m0bl0]

Hi,

only some of Equalizer's threading primitives/helper classes have EQ_EXPORTS:
Thread itself, Lock, TimedLock and RequestHandler do, but Atomic, Monitor, MTQueue and ScopedMutex (any reason why this isn't called ScopedLock?) don't.
Is this intentional, or just a case of not-necessarily-final APIs again?

Cheers,
Marc

[Stefan Eilemann]

Hi Marc,

On 26. Sep 2009, at 23:34, m0bl0 (via Nabble) wrote:

> only some of Equalizer's threading primitives/helper classes have  
> EQ_EXPORTS:
> Thread itself, Lock, TimedLock and RequestHandler do, but Atomic,  
> Monitor, MTQueue and ScopedMutex (any reason why this isn't called  
> ScopedLock?) don't.
> Is this intentional, or just a case of not-necessarily-final APIs  
> again?

As far as I can see, they are all inlined. Are you having troubles  
using them on Windows? I haven't tested that, there might be an issue  
with the explicit template instantiation.

Btw, you need to manually include pthread.h before including these  
classes if you want to instantiate new types. We don't want to do this  
automatically due to conflicting type declarations with other libraries.

The eq::base API is finalized.


Cheers,

Stefan.

[m0bl0]

Stefan Eilemann wrote:

As far as I can see, they are all inlined. Are you having troubles  
using them on Windows? I haven't tested that, there might be an issue  
with the explicit template instantiation.

Hm, apparently there is: If I include pthread.h myself, it works; if I don't, the linker complains about unresolved externals, even though I only use a Monitor< bool >. Btw, this is on VS 2008; don't have 2005 available to try if it behaves differently.

Cheers,
Marc

[Stefan Eilemann]

On 28. Sep 2009, at 13:48, m0bl0 (via Nabble) wrote:

> Hm, apparently there is: If I include pthread.h myself, it works; if  
> I don't, the linker complains about unresolved externals, even  
> though I only use a Monitor< bool >. Btw, this is on VS 2008; don't  
> have 2005 available to try if it behaves differently.

Ok, so if you include pthread.h you have the implementation, and the  
compiler instantiates it again. What happens if you do not include it,  
but EQ_EXPORT all relevant methods? I guess this would be the way to go.


Cheer,

Stefan.

[m0bl0]

Stefan Eilemann wrote:

Ok, so if you include pthread.h you have the implementation, and the  
compiler instantiates it again. What happens if you do not include it,  
but EQ_EXPORT all relevant methods? I guess this would be the way to go.

I already tried that, but then including e.g. monitor.h after pthread.h fails ("definition of dllimport function not allowed").

This seems to work:

#if defined(EQUALIZER_EXPORTS) || !defined(HAVE_PTHREAD_H)
#  define LOCAL_EQ_EXPORT EQ_EXPORT
#else
#  define LOCAL_EQ_EXPORT
#endif

(plus adding LOCAL_EQ_EXPORT to all relevant methods, obviously), but it's not exactly pretty.. and if you do include pthread.h before monitor.h, Monitor< bool > etc will still be instantiated again. But better than nothing, maybe? I'm out of ideas now ;)

Cheers,
Marc

[Stefan Eilemann]

On Mon, Sep 28, 2009 at 2:39 PM, m0bl0 (via Nabble)
<[hidden email]> wrote:
> I'm out of ideas now ;)

Me too. I've tweaked and implemented your idea for Monitor - can you
test it and tell me if it works?

I'll then apply it to the other classes.


Cheers,

Stefan.

[m0bl0]

Stefan Eilemann wrote:

Me too. I've tweaked and implemented your idea for Monitor - can you
test it and tell me if it works?

I'll then apply it to the other classes.

Almost:

There is still an EQ_PT_EXPORT missing on _construct() (line 150), which is called by the inlined Ctors.

And on line 157/158, operator <<: First, the EQ_PT_EXPORT needs to go after the template< typename T >, like this:

template< typename T >
EQ_PT_EXPORT std::ostream& operator << ( std::ostream& os, const Monitor<T>& monitor );

Then Equalizer compiles again, but I still get unresolved externals about the <<, which is expected because it's not explicitly instantiated. But adding

template std::ostream& operator << < uint32_t > ( std::ostream& os, const Monitor< uint32_t >& monitor );
template std::ostream& operator << < bool >     ( std::ostream& os, const Monitor< bool >&     monitor );

to monitor.cpp doesn't seem to change anything. Am I still missing something here..?

Thanks,
Marc

[Stefan Eilemann]

Hi Marc,

I've found a solution (see rev 3406). Since I am a bit busy, can you
send me a patch for the other files?


Cheers,

Stefan.

[m0bl0]

Stefan Eilemann wrote:

I've found a solution (see rev 3406). Since I am a bit busy, can you
send me a patch for the other files?

I would.. but I just looked over the files again, the only classes with the same problem are MTQueue, PerThread and PerThreadRef, and they all don't have default instantiations, so it doesn't really matter if their methods are exported. Do you want the patch anyway? (Or should I also add some default instantiations?)

Cheers,
Marc

[Stefan Eilemann]

On Tue, Sep 29, 2009 at 1:24 PM, m0bl0 (via Nabble)
<[hidden email]> wrote:
> I would.. but I just looked over the files again, the only classes with the
> same problem are MTQueue, PerThread and PerThreadRef, and they all don't
> have default instantiations, so it doesn't really matter if their methods
> are exported. Do you want the patch anyway?

No, that's fine then. I'll just add the comment to the doxygen.


Cheers,

Stefan.