public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
* RE: [pthreads-win32] How can you use errno with pthreads DLL?
@ 2003-11-19 23:37 Pedriana, Paul
  0 siblings, 0 replies; 3+ messages in thread
From: Pedriana, Paul @ 2003-11-19 23:37 UTC (permalink / raw)
  To: Mark Weaver, pthreads-win32

   >>1. Recompile pthreads against the same runtime 
   >>library that you are using rather than MSVC.  
   >>This is more than likely the best solution as 
   >>having two different CRTs is nasty bloat: think 
   >>two separate heaps and copies of all support data 
   >>structure, not to mention the additional code size.

This is a good idea which would work. I might point out that 
we don't use the CRT for the most part; it is somewhat non-portable
(can't rely on half of the useful stuff existing elsewhere)
and not necessarily very efficient (with some exceptions), 
and we need both. So duplicating CRTs really has little ill 
effect for us. Also, VC++ no longer uses its own heap but 
rather redirects all allocations to the OS under WinXP and 
later OSs. 


   >>2. Explicitly import and use the function "_errno" 
   >>from MSVCRT.DLL.

OK, this is a good idea too. I was just hoping that pthreads 
could simply make such a thing available itself, as IMO it is 
not a good idea for a utility library to force the apps that 
use it to use a particular library configuration (in particular
one that has a history of causing problems for commercial software
developers due to problems with that way Windows deals with linked
libraries). What happens if I have another DLL from somebody 
else that has the exact opposite requirement (must use own CRT 
and not shared one)? 


   >>sem_* and sched_* do, so if you don't use those you 
   >>could bypass this problem.

Yah, it's the semaphore functions that write to errno and the ones
that are an issue for me. I thought I read somewhere that there was
a proposal to migrate sem_* to return error values and zero upon 
OK, but that's another story.

Thanks so much for the response. I will find a way to do one of the 
above or add my own GetErrno function to my copy of pthreads. I find
that pthreads-win32 is a great thing and am very grateful for the 
work that has been put into it.










^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: [pthreads-win32] How can you use errno with pthreads DLL?
  2003-11-19  3:45 Pedriana, Paul
@ 2003-11-19  6:27 ` Mark Weaver
  0 siblings, 0 replies; 3+ messages in thread
From: Mark Weaver @ 2003-11-19  6:27 UTC (permalink / raw)
  To: pthreads-win32

>
> I am trying to use pthreads-win32 but have run into a problem. I get an
> error return value from pthreads-win32 but I can't use the errno because
> pthreads-win32 uses the errno for its C runtime library but my app uses
> its own errno from its C runtime library. How do I read the errno from
> pthreads-win32's view of things inside its DLL? I don't see a function
> for such a thing. I looked at the pthread.dsp file and it is set to use
> "Multithreaded DLL" library mode, so I figure that pthreads-win32 is
> more or less forcing me to use that mode. Well my application doesn't
> use that and can't do so.
>
> So is it not possible for there to simply be a pthreads-win32 function
> to get the errno? It may not be highly pretty but as it stands right now
> pthreads-win32 is unusable because of this problem.
>
Well it seems to me that you have a few options here:

1. Recompile pthreads against the same runtime library that you are using
rather than MSVC.  This is more than likely the best solution as having two
different CRTs is nasty bloat: think two separate heaps and copies of all
support data structure, not to mention the additional code size.

2. Explicitly import and use the function "_errno" from MSVCRT.DLL.  To
avoid the linker going nuts with two copies of most of the standard C
library symbols the least painful way to do this is to use LoadLibrary and
GetProcAddress. _errno basically is a wrapper around some thread local
storage: errno needs to be per thread in a multi-threaded environment.

TBH, I thought that pthreads didn't really use errno but opted to return an
errno.h defined status code.  sem_* and sched_* do, so if you don't use
those you could bypass this problem.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [pthreads-win32] How can you use errno with pthreads DLL?
@ 2003-11-19  3:45 Pedriana, Paul
  2003-11-19  6:27 ` Mark Weaver
  0 siblings, 1 reply; 3+ messages in thread
From: Pedriana, Paul @ 2003-11-19  3:45 UTC (permalink / raw)
  To: pthreads-win32

I am trying to use pthreads-win32 but have run into a problem. I get an
error return value from pthreads-win32 but I can't use the errno because
pthreads-win32 uses the errno for its C runtime library but my app uses
its own errno from its C runtime library. How do I read the errno from
pthreads-win32's view of things inside its DLL? I don't see a function
for such a thing. I looked at the pthread.dsp file and it is set to use
"Multithreaded DLL" library mode, so I figure that pthreads-win32 is
more or less forcing me to use that mode. Well my application doesn't
use that and can't do so.

So is it not possible for there to simply be a pthreads-win32 function
to get the errno? It may not be highly pretty but as it stands right now
pthreads-win32 is unusable because of this problem. 

I couldn't find anything about this while searching the archives, but on
the other hand I can't believe that nobody has ran into this before. So
perhaps I am a booby-head and am completely misunderstanding things or
not realizing something.

Thanks.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-11-19 23:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-19 23:37 [pthreads-win32] How can you use errno with pthreads DLL? Pedriana, Paul
  -- strict thread matches above, loose matches on Subject: below --
2003-11-19  3:45 Pedriana, Paul
2003-11-19  6:27 ` Mark Weaver

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).