You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Chris Cates <cc...@idlehands.net> on 2004/12/08 19:38:20 UTC
macosx and sockets implementation question
Greetings,
I'm currently using xerces-c 2.6 built on MacOS X 10.3 with sockets as
net access. (Which works very nicely, btw.)
I was wondering why MacOSPlatformUtils' implementation of
makeNetAccessor() does not create and return a SocketNetAccessor by
default if it sees that the XML_USE_NETACCESSOR_SOCKET #define is set.
I've tried this locally in my own build, and at first glance, it seems
to work fine and save the user from setting fgNetAccessor manually when
using sockets.
Any reason this is not a part of the MacOSPlatformUtils by default? Is
there something that I'm missing?
Thanks!
-Chris
ccates@idlehands.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Thread safety of MacOSUnicodeConverter::compareIString()?
Posted by Chris Cates <cc...@idlehands.net>.
Hi James,
So sorry to take so long to get back to you, but I was out of town.
I'll grab the changes and do some testing. Thanks for your time!
I'll let you know how it goes...
-Chris
On Feb 11, 2005, at 4:47 PM, James Berry wrote:
> Chris,
>
> I just checked in a code revision that implements (2b). Could you
> please review, when you get a chance, to see if this resolves the
> problem you reported?
>
> James.
>
> On Jan 19, 2005, at 2:42 PM, Chris Cates wrote:
>
>> Hey James,
>> Thanks very much for the response. I'm definitely in favor of option
>> (2b).
>> First of all, I'm out of my league in this part of the code, so I'll
>> have to leave the writing to you. I'm more than happy to help test
>> whatever you'd like, tho. Second, the problem isn't very reliably
>> reproducible right now (thanks to the timing of the threads, no
>> doubt). I'm going to spend some time seeing if I can get it to
>> happen more predictably to make any testing more reliable.
>> Thanks, and just drop me a note on what I can do to help.
>> -Chris
>> On Jan 19, 2005, at 3:42 PM, James Berry wrote:
>>> Hi Chris,
>>> Oops. I don't have any confirmation that UCCompareTextDefault is
>>> thread safe, although my general impression through the years is
>>> that the UnicodeConverter, in general, is...within certain
>>> guidelines.
>>> But it sounds (and looks) like you've come up with a case where it
>>> isn't. It looks like there's a race condition in the code having to
>>> do with deallocation of the collator used internally by
>>> UCCompareTextDefault...which wouldn't really be optimal anyway.
>>> You've got two choices:
>>> (1) Switch to using the icu transcoder (it's interesting that the
>>> UC routine is actually failing in a call to icu... ;)
>>> (2) Work with me to fix this problem in the MacOSUnicodeConverter.
>>> (3) Or both.
>>> To fix MacOSUnicodeConverter, we've got several choices:
>>> (a) Rewrite those comparison routines to use CFString functions for
>>> the comparisons (similar to implementation of
>>> MacOSUnicodeConverter::upperCase). This pays the penalty of a
>>> malloc/dealloc per call, which isn't too nice. But this should be
>>> thread-safe otherwise.
>>> (b) Rewrite those comparison routines to use a fixed instance of a
>>> UCCreateCollator that we allocate ourselves during construction of
>>> the MacOSUnicodeConverter.. At least we'll be able to control the
>>> lifetime of the collator this way. Since we'll have a single
>>> instance of this collator for Xerces, we'll hope that it's
>>> re-entrant...which I believe it to be. We'll then use UCCompareText
>>> instead of UCCompareTextDefault. This should get around the fact
>>> that UCCompareTextDefault is apparently not properly protecting the
>>> collator that it uses internally. If we had to, we could put a mutex
>>> around the use of our collator.
>>> (c) Some other choice.
>>> Since you've got a somewhat reproducible test, I'd love it if you'd
>>> help me write and/or test 2b.
>>> -jdb
>>> On Jan 19, 2005, at 11:40 AM, Chris Cates wrote:
>>>> I have an odd problem that I was wondering if anyone has seen
>>>> before or could maybe offer some input on.
>>>> I'm using xerces 2.6.0 on MacOS 10.3.7, and my application is
>>>> multi-threaded. There are two threads using xerces, each with its
>>>> own parser and associated data. I have seen a seg fault a couple
>>>> times now from these threads with identical stack traces on both of
>>>> the xerces threads. (Both threads stacks are included at the bottom
>>>> from a single crash.)
>>>> The only guess I've been able to come up with for what's going on
>>>> is that the Apple Carbon routine UCCompareTextDefault() is not
>>>> thread-safe. I was wondering if anyone has run into anything like
>>>> this before, or knows whether indeed, it may be a threading issue
>>>> related to the Apple routines.
>>>> Help? Thanks very much in advance.
>>>> -Chris
>>>> ------------------------------
>>>> Thread 2 Crashed:
>>>> 0 libicucore.A.dylib 0x968d2208 ures_close + 0x18
>>>> 1 libicucore.A.dylib 0x968e9fe8 ucol_close + 0xa8
>>>> 2 ...ple.CoreServices.CarbonCore 0x902ce4c4 SetICUCollator + 0x30
>>>> 3 ...ple.CoreServices.CarbonCore 0x902a4e58 UCCompareTextDefault
>>>> + 0x98
>>>> 4 libxerces-c.26.0.dylib 0x014f0e5c
>>>> xercesc_2_6::MacOSUnicodeConverter::compareIString(unsigned short
>>>> const*, unsigned short const*) + 0xc0
>>>> 5 libxerces-c.26.0.dylib 0x01567174
>>>> xercesc_2_6::XMLString::compareIString(unsigned short const*,
>>>> unsigned short const*) + 0x40
>>>> 6 libxerces-c.26.0.dylib 0x01569c48
>>>> xercesc_2_6::XMLURL::lookupByName(unsigned short const*) + 0x3c
>>>> 7 libxerces-c.26.0.dylib 0x0156c4dc
>>>> xercesc_2_6::XMLURL::parse(unsigned short const*) + 0x284
>>>> 8 libxerces-c.26.0.dylib 0x0156adc0
>>>> xercesc_2_6::XMLURL::setURL(unsigned short const*) + 0x28
>>>> 9 libxerces-c.26.0.dylib 0x0156a314
>>>> _ZN11xercesc_2_66XMLURLC4EPKcPNS_13MemoryManagerE + 0x8c
>>>> 10 libxerces-c.26.0.dylib 0x0156a278
>>>> xercesc_2_6::XMLURL::XMLURL(char const*,
>>>> xercesc_2_6::MemoryManager*) + 0x10
>>>> 11 intercomd 0x0003250c
>>>> xml::DomParser::ParseURL(std::basic_string<char,
>>>> std::char_traits<char>, std::allocator<char> > const&) + 0x310
>>>> 12 intercomd 0x000cb384 weather::Parser::Update() + 0x3c4
>>>> 13 intercomd 0x00098abc weather::Implementation::DoUpdate(bool,
>>>> bool, bool) + 0x354
>>>> 14 intercomd 0x000d3bdc weather::Thread::execute() + 0x69c
>>>> 15 intercomd 0x00029054 util::Thread::run() + 0x38
>>>> 16 intercomd 0x0002909c util::Thread::threadFunction(void*) + 0x34
>>>> 17 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28
>>>> Thread 3 Crashed:
>>>> 0 libicucore.A.dylib 0x968d2208 ures_close + 0x18
>>>> 1 libicucore.A.dylib 0x968e9fe8 ucol_close + 0xa8
>>>> 2 ...ple.CoreServices.CarbonCore 0x902ce4c4 SetICUCollator + 0x30
>>>> 3 ...ple.CoreServices.CarbonCore 0x902a4e58 UCCompareTextDefault
>>>> + 0x98
>>>> 4 libxerces-c.26.0.dylib 0x014f0e5c
>>>> xercesc_2_6::MacOSUnicodeConverter::compareIString(unsigned short
>>>> const*, unsigned short const*) + 0xc0
>>>> 5 libxerces-c.26.0.dylib 0x01567174
>>>> xercesc_2_6::XMLString::compareIString(unsigned short const*,
>>>> unsigned short const*) + 0x40
>>>> 6 libxerces-c.26.0.dylib 0x01569c48
>>>> xercesc_2_6::XMLURL::lookupByName(unsigned short const*) + 0x3c
>>>> 7 libxerces-c.26.0.dylib 0x0156c4dc
>>>> xercesc_2_6::XMLURL::parse(unsigned short const*) + 0x284
>>>> 8 libxerces-c.26.0.dylib 0x0156adc0
>>>> xercesc_2_6::XMLURL::setURL(unsigned short const*) + 0x28
>>>> 9 libxerces-c.26.0.dylib 0x0156a314
>>>> _ZN11xercesc_2_66XMLURLC4EPKcPNS_13MemoryManagerE + 0x8c
>>>> 10 libxerces-c.26.0.dylib 0x0156a278
>>>> xercesc_2_6::XMLURL::XMLURL(char const*,
>>>> xercesc_2_6::MemoryManager*) + 0x10
>>>> 11 intercomd 0x0003250c
>>>> xml::DomParser::ParseURL(std::basic_string<char,
>>>> std::char_traits<char>, std::allocator<char> > const&) + 0x310
>>>> 12 intercomd 0x000b7838 rss::Parser::Parse(std::basic_string<char,
>>>> std::char_traits<char>, std::allocator<char> > const&) + 0x314
>>>> 13 intercomd 0x0008a834 rss::Implementation::DoUpdate() + 0x2d8
>>>> 14 intercomd 0x000b9b48 rss::Thread::execute() + 0x5cc
>>>> 15 intercomd 0x00029054 util::Thread::run() + 0x38
>>>> 16 intercomd 0x0002909c util::Thread::threadFunction(void*) + 0x34
>>>> 17 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28
>>>> --------------------------------------------------------------------
>>>> -
>>>> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>>>> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Thread safety of MacOSUnicodeConverter::compareIString()?
Posted by James Berry <jb...@apache.org>.
Chris,
I just checked in a code revision that implements (2b). Could you
please review, when you get a chance, to see if this resolves the
problem you reported?
James.
On Jan 19, 2005, at 2:42 PM, Chris Cates wrote:
> Hey James,
> Thanks very much for the response. I'm definitely in favor of option
> (2b).
> First of all, I'm out of my league in this part of the code, so I'll
> have to leave the writing to you. I'm more than happy to help test
> whatever you'd like, tho. Second, the problem isn't very reliably
> reproducible right now (thanks to the timing of the threads, no
> doubt). I'm going to spend some time seeing if I can get it to happen
> more predictably to make any testing more reliable.
> Thanks, and just drop me a note on what I can do to help.
> -Chris
> On Jan 19, 2005, at 3:42 PM, James Berry wrote:
>> Hi Chris,
>> Oops. I don't have any confirmation that UCCompareTextDefault is
>> thread safe, although my general impression through the years is that
>> the UnicodeConverter, in general, is...within certain guidelines.
>> But it sounds (and looks) like you've come up with a case where it
>> isn't. It looks like there's a race condition in the code having to
>> do with deallocation of the collator used internally by
>> UCCompareTextDefault...which wouldn't really be optimal anyway.
>> You've got two choices:
>> (1) Switch to using the icu transcoder (it's interesting that the UC
>> routine is actually failing in a call to icu... ;)
>> (2) Work with me to fix this problem in the MacOSUnicodeConverter.
>> (3) Or both.
>> To fix MacOSUnicodeConverter, we've got several choices:
>> (a) Rewrite those comparison routines to use CFString functions for
>> the comparisons (similar to implementation of
>> MacOSUnicodeConverter::upperCase). This pays the penalty of a
>> malloc/dealloc per call, which isn't too nice. But this should be
>> thread-safe otherwise.
>> (b) Rewrite those comparison routines to use a fixed instance of a
>> UCCreateCollator that we allocate ourselves during construction of
>> the MacOSUnicodeConverter.. At least we'll be able to control the
>> lifetime of the collator this way. Since we'll have a single instance
>> of this collator for Xerces, we'll hope that it's re-entrant...which
>> I believe it to be. We'll then use UCCompareText instead of
>> UCCompareTextDefault. This should get around the fact that
>> UCCompareTextDefault is apparently not properly protecting the
>> collator that it uses internally. If we had to, we could put a mutex
>> around the use of our collator.
>> (c) Some other choice.
>> Since you've got a somewhat reproducible test, I'd love it if you'd
>> help me write and/or test 2b.
>> -jdb
>> On Jan 19, 2005, at 11:40 AM, Chris Cates wrote:
>>> I have an odd problem that I was wondering if anyone has seen before
>>> or could maybe offer some input on.
>>> I'm using xerces 2.6.0 on MacOS 10.3.7, and my application is
>>> multi-threaded. There are two threads using xerces, each with its
>>> own parser and associated data. I have seen a seg fault a couple
>>> times now from these threads with identical stack traces on both of
>>> the xerces threads. (Both threads stacks are included at the bottom
>>> from a single crash.)
>>> The only guess I've been able to come up with for what's going on is
>>> that the Apple Carbon routine UCCompareTextDefault() is not
>>> thread-safe. I was wondering if anyone has run into anything like
>>> this before, or knows whether indeed, it may be a threading issue
>>> related to the Apple routines.
>>> Help? Thanks very much in advance.
>>> -Chris
>>> ------------------------------
>>> Thread 2 Crashed:
>>> 0 libicucore.A.dylib 0x968d2208 ures_close + 0x18
>>> 1 libicucore.A.dylib 0x968e9fe8 ucol_close + 0xa8
>>> 2 ...ple.CoreServices.CarbonCore 0x902ce4c4 SetICUCollator + 0x30
>>> 3 ...ple.CoreServices.CarbonCore 0x902a4e58 UCCompareTextDefault +
>>> 0x98
>>> 4 libxerces-c.26.0.dylib 0x014f0e5c
>>> xercesc_2_6::MacOSUnicodeConverter::compareIString(unsigned short
>>> const*, unsigned short const*) + 0xc0
>>> 5 libxerces-c.26.0.dylib 0x01567174
>>> xercesc_2_6::XMLString::compareIString(unsigned short const*,
>>> unsigned short const*) + 0x40
>>> 6 libxerces-c.26.0.dylib 0x01569c48
>>> xercesc_2_6::XMLURL::lookupByName(unsigned short const*) + 0x3c
>>> 7 libxerces-c.26.0.dylib 0x0156c4dc
>>> xercesc_2_6::XMLURL::parse(unsigned short const*) + 0x284
>>> 8 libxerces-c.26.0.dylib 0x0156adc0
>>> xercesc_2_6::XMLURL::setURL(unsigned short const*) + 0x28
>>> 9 libxerces-c.26.0.dylib 0x0156a314
>>> _ZN11xercesc_2_66XMLURLC4EPKcPNS_13MemoryManagerE + 0x8c
>>> 10 libxerces-c.26.0.dylib 0x0156a278
>>> xercesc_2_6::XMLURL::XMLURL(char const*,
>>> xercesc_2_6::MemoryManager*) + 0x10
>>> 11 intercomd 0x0003250c
>>> xml::DomParser::ParseURL(std::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const&) + 0x310
>>> 12 intercomd 0x000cb384 weather::Parser::Update() + 0x3c4
>>> 13 intercomd 0x00098abc weather::Implementation::DoUpdate(bool,
>>> bool, bool) + 0x354
>>> 14 intercomd 0x000d3bdc weather::Thread::execute() + 0x69c
>>> 15 intercomd 0x00029054 util::Thread::run() + 0x38
>>> 16 intercomd 0x0002909c util::Thread::threadFunction(void*) + 0x34
>>> 17 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28
>>> Thread 3 Crashed:
>>> 0 libicucore.A.dylib 0x968d2208 ures_close + 0x18
>>> 1 libicucore.A.dylib 0x968e9fe8 ucol_close + 0xa8
>>> 2 ...ple.CoreServices.CarbonCore 0x902ce4c4 SetICUCollator + 0x30
>>> 3 ...ple.CoreServices.CarbonCore 0x902a4e58 UCCompareTextDefault +
>>> 0x98
>>> 4 libxerces-c.26.0.dylib 0x014f0e5c
>>> xercesc_2_6::MacOSUnicodeConverter::compareIString(unsigned short
>>> const*, unsigned short const*) + 0xc0
>>> 5 libxerces-c.26.0.dylib 0x01567174
>>> xercesc_2_6::XMLString::compareIString(unsigned short const*,
>>> unsigned short const*) + 0x40
>>> 6 libxerces-c.26.0.dylib 0x01569c48
>>> xercesc_2_6::XMLURL::lookupByName(unsigned short const*) + 0x3c
>>> 7 libxerces-c.26.0.dylib 0x0156c4dc
>>> xercesc_2_6::XMLURL::parse(unsigned short const*) + 0x284
>>> 8 libxerces-c.26.0.dylib 0x0156adc0
>>> xercesc_2_6::XMLURL::setURL(unsigned short const*) + 0x28
>>> 9 libxerces-c.26.0.dylib 0x0156a314
>>> _ZN11xercesc_2_66XMLURLC4EPKcPNS_13MemoryManagerE + 0x8c
>>> 10 libxerces-c.26.0.dylib 0x0156a278
>>> xercesc_2_6::XMLURL::XMLURL(char const*,
>>> xercesc_2_6::MemoryManager*) + 0x10
>>> 11 intercomd 0x0003250c
>>> xml::DomParser::ParseURL(std::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const&) + 0x310
>>> 12 intercomd 0x000b7838 rss::Parser::Parse(std::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const&) + 0x314
>>> 13 intercomd 0x0008a834 rss::Implementation::DoUpdate() + 0x2d8
>>> 14 intercomd 0x000b9b48 rss::Thread::execute() + 0x5cc
>>> 15 intercomd 0x00029054 util::Thread::run() + 0x38
>>> 16 intercomd 0x0002909c util::Thread::threadFunction(void*) + 0x34
>>> 17 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>>> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Thread safety of MacOSUnicodeConverter::compareIString()?
Posted by Chris Cates <cc...@idlehands.net>.
Hey James,
Thanks very much for the response. I'm definitely in favor of option
(2b).
First of all, I'm out of my league in this part of the code, so I'll
have to leave the writing to you. I'm more than happy to help test
whatever you'd like, tho. Second, the problem isn't very reliably
reproducible right now (thanks to the timing of the threads, no doubt).
I'm going to spend some time seeing if I can get it to happen more
predictably to make any testing more reliable.
Thanks, and just drop me a note on what I can do to help.
-Chris
On Jan 19, 2005, at 3:42 PM, James Berry wrote:
> Hi Chris,
>
> Oops. I don't have any confirmation that UCCompareTextDefault is
> thread safe, although my general impression through the years is that
> the UnicodeConverter, in general, is...within certain guidelines.
>
> But it sounds (and looks) like you've come up with a case where it
> isn't. It looks like there's a race condition in the code having to do
> with deallocation of the collator used internally by
> UCCompareTextDefault...which wouldn't really be optimal anyway.
>
> You've got two choices:
>
> (1) Switch to using the icu transcoder (it's interesting that the UC
> routine is actually failing in a call to icu... ;)
>
> (2) Work with me to fix this problem in the MacOSUnicodeConverter.
>
> (3) Or both.
>
> To fix MacOSUnicodeConverter, we've got several choices:
>
> (a) Rewrite those comparison routines to use CFString functions for
> the comparisons (similar to implementation of
> MacOSUnicodeConverter::upperCase). This pays the penalty of a
> malloc/dealloc per call, which isn't too nice. But this should be
> thread-safe otherwise.
>
> (b) Rewrite those comparison routines to use a fixed instance of a
> UCCreateCollator that we allocate ourselves during construction of the
> MacOSUnicodeConverter.. At least we'll be able to control the lifetime
> of the collator this way. Since we'll have a single instance of this
> collator for Xerces, we'll hope that it's re-entrant...which I believe
> it to be. We'll then use UCCompareText instead of
> UCCompareTextDefault. This should get around the fact that
> UCCompareTextDefault is apparently not properly protecting the
> collator that it uses internally. If we had to, we could put a mutex
> around the use of our collator.
>
> (c) Some other choice.
>
> Since you've got a somewhat reproducible test, I'd love it if you'd
> help me write and/or test 2b.
>
> -jdb
>
>
> On Jan 19, 2005, at 11:40 AM, Chris Cates wrote:
>
>> I have an odd problem that I was wondering if anyone has seen before
>> or could maybe offer some input on.
>>
>> I'm using xerces 2.6.0 on MacOS 10.3.7, and my application is
>> multi-threaded. There are two threads using xerces, each with its own
>> parser and associated data. I have seen a seg fault a couple times
>> now from these threads with identical stack traces on both of the
>> xerces threads. (Both threads stacks are included at the bottom from
>> a single crash.)
>>
>> The only guess I've been able to come up with for what's going on is
>> that the Apple Carbon routine UCCompareTextDefault() is not
>> thread-safe. I was wondering if anyone has run into anything like
>> this before, or knows whether indeed, it may be a threading issue
>> related to the Apple routines.
>>
>> Help? Thanks very much in advance.
>> -Chris
>>
>>
>> ------------------------------
>> Thread 2 Crashed:
>> 0 libicucore.A.dylib 0x968d2208 ures_close + 0x18
>> 1 libicucore.A.dylib 0x968e9fe8 ucol_close + 0xa8
>> 2 ...ple.CoreServices.CarbonCore 0x902ce4c4 SetICUCollator + 0x30
>> 3 ...ple.CoreServices.CarbonCore 0x902a4e58 UCCompareTextDefault +
>> 0x98
>> 4 libxerces-c.26.0.dylib 0x014f0e5c
>> xercesc_2_6::MacOSUnicodeConverter::compareIString(unsigned short
>> const*, unsigned short const*) + 0xc0
>> 5 libxerces-c.26.0.dylib 0x01567174
>> xercesc_2_6::XMLString::compareIString(unsigned short const*,
>> unsigned short const*) + 0x40
>> 6 libxerces-c.26.0.dylib 0x01569c48
>> xercesc_2_6::XMLURL::lookupByName(unsigned short const*) + 0x3c
>> 7 libxerces-c.26.0.dylib 0x0156c4dc
>> xercesc_2_6::XMLURL::parse(unsigned short const*) + 0x284
>> 8 libxerces-c.26.0.dylib 0x0156adc0
>> xercesc_2_6::XMLURL::setURL(unsigned short const*) + 0x28
>> 9 libxerces-c.26.0.dylib 0x0156a314
>> _ZN11xercesc_2_66XMLURLC4EPKcPNS_13MemoryManagerE + 0x8c
>> 10 libxerces-c.26.0.dylib 0x0156a278
>> xercesc_2_6::XMLURL::XMLURL(char const*, xercesc_2_6::MemoryManager*)
>> + 0x10
>> 11 intercomd 0x0003250c
>> xml::DomParser::ParseURL(std::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const&) + 0x310
>> 12 intercomd 0x000cb384 weather::Parser::Update() + 0x3c4
>> 13 intercomd 0x00098abc weather::Implementation::DoUpdate(bool, bool,
>> bool) + 0x354
>> 14 intercomd 0x000d3bdc weather::Thread::execute() + 0x69c
>> 15 intercomd 0x00029054 util::Thread::run() + 0x38
>> 16 intercomd 0x0002909c util::Thread::threadFunction(void*) + 0x34
>> 17 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28
>>
>> Thread 3 Crashed:
>> 0 libicucore.A.dylib 0x968d2208 ures_close + 0x18
>> 1 libicucore.A.dylib 0x968e9fe8 ucol_close + 0xa8
>> 2 ...ple.CoreServices.CarbonCore 0x902ce4c4 SetICUCollator + 0x30
>> 3 ...ple.CoreServices.CarbonCore 0x902a4e58 UCCompareTextDefault +
>> 0x98
>> 4 libxerces-c.26.0.dylib 0x014f0e5c
>> xercesc_2_6::MacOSUnicodeConverter::compareIString(unsigned short
>> const*, unsigned short const*) + 0xc0
>> 5 libxerces-c.26.0.dylib 0x01567174
>> xercesc_2_6::XMLString::compareIString(unsigned short const*,
>> unsigned short const*) + 0x40
>> 6 libxerces-c.26.0.dylib 0x01569c48
>> xercesc_2_6::XMLURL::lookupByName(unsigned short const*) + 0x3c
>> 7 libxerces-c.26.0.dylib 0x0156c4dc
>> xercesc_2_6::XMLURL::parse(unsigned short const*) + 0x284
>> 8 libxerces-c.26.0.dylib 0x0156adc0
>> xercesc_2_6::XMLURL::setURL(unsigned short const*) + 0x28
>> 9 libxerces-c.26.0.dylib 0x0156a314
>> _ZN11xercesc_2_66XMLURLC4EPKcPNS_13MemoryManagerE + 0x8c
>> 10 libxerces-c.26.0.dylib 0x0156a278
>> xercesc_2_6::XMLURL::XMLURL(char const*, xercesc_2_6::MemoryManager*)
>> + 0x10
>> 11 intercomd 0x0003250c
>> xml::DomParser::ParseURL(std::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const&) + 0x310
>> 12 intercomd 0x000b7838 rss::Parser::Parse(std::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const&) + 0x314
>> 13 intercomd 0x0008a834 rss::Implementation::DoUpdate() + 0x2d8
>> 14 intercomd 0x000b9b48 rss::Thread::execute() + 0x5cc
>> 15 intercomd 0x00029054 util::Thread::run() + 0x38
>> 16 intercomd 0x0002909c util::Thread::threadFunction(void*) + 0x34
>> 17 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Thread safety of MacOSUnicodeConverter::compareIString()?
Posted by James Berry <jb...@apache.org>.
Hi Chris,
Oops. I don't have any confirmation that UCCompareTextDefault is thread
safe, although my general impression through the years is that the
UnicodeConverter, in general, is...within certain guidelines.
But it sounds (and looks) like you've come up with a case where it
isn't. It looks like there's a race condition in the code having to do
with deallocation of the collator used internally by
UCCompareTextDefault...which wouldn't really be optimal anyway.
You've got two choices:
(1) Switch to using the icu transcoder (it's interesting that the UC
routine is actually failing in a call to icu... ;)
(2) Work with me to fix this problem in the MacOSUnicodeConverter.
(3) Or both.
To fix MacOSUnicodeConverter, we've got several choices:
(a) Rewrite those comparison routines to use CFString functions for
the comparisons (similar to implementation of
MacOSUnicodeConverter::upperCase). This pays the penalty of a
malloc/dealloc per call, which isn't too nice. But this should be
thread-safe otherwise.
(b) Rewrite those comparison routines to use a fixed instance of a
UCCreateCollator that we allocate ourselves during construction of the
MacOSUnicodeConverter.. At least we'll be able to control the lifetime
of the collator this way. Since we'll have a single instance of this
collator for Xerces, we'll hope that it's re-entrant...which I believe
it to be. We'll then use UCCompareText instead of UCCompareTextDefault.
This should get around the fact that UCCompareTextDefault is
apparently not properly protecting the collator that it uses
internally. If we had to, we could put a mutex around the use of our
collator.
(c) Some other choice.
Since you've got a somewhat reproducible test, I'd love it if you'd
help me write and/or test 2b.
-jdb
On Jan 19, 2005, at 11:40 AM, Chris Cates wrote:
> I have an odd problem that I was wondering if anyone has seen before
> or could maybe offer some input on.
>
> I'm using xerces 2.6.0 on MacOS 10.3.7, and my application is
> multi-threaded. There are two threads using xerces, each with its own
> parser and associated data. I have seen a seg fault a couple times now
> from these threads with identical stack traces on both of the xerces
> threads. (Both threads stacks are included at the bottom from a single
> crash.)
>
> The only guess I've been able to come up with for what's going on is
> that the Apple Carbon routine UCCompareTextDefault() is not
> thread-safe. I was wondering if anyone has run into anything like this
> before, or knows whether indeed, it may be a threading issue related
> to the Apple routines.
>
> Help? Thanks very much in advance.
> -Chris
>
>
> ------------------------------
> Thread 2 Crashed:
> 0 libicucore.A.dylib 0x968d2208 ures_close + 0x18
> 1 libicucore.A.dylib 0x968e9fe8 ucol_close + 0xa8
> 2 ...ple.CoreServices.CarbonCore 0x902ce4c4 SetICUCollator + 0x30
> 3 ...ple.CoreServices.CarbonCore 0x902a4e58 UCCompareTextDefault +
> 0x98
> 4 libxerces-c.26.0.dylib 0x014f0e5c
> xercesc_2_6::MacOSUnicodeConverter::compareIString(unsigned short
> const*, unsigned short const*) + 0xc0
> 5 libxerces-c.26.0.dylib 0x01567174
> xercesc_2_6::XMLString::compareIString(unsigned short const*, unsigned
> short const*) + 0x40
> 6 libxerces-c.26.0.dylib 0x01569c48
> xercesc_2_6::XMLURL::lookupByName(unsigned short const*) + 0x3c
> 7 libxerces-c.26.0.dylib 0x0156c4dc
> xercesc_2_6::XMLURL::parse(unsigned short const*) + 0x284
> 8 libxerces-c.26.0.dylib 0x0156adc0
> xercesc_2_6::XMLURL::setURL(unsigned short const*) + 0x28
> 9 libxerces-c.26.0.dylib 0x0156a314
> _ZN11xercesc_2_66XMLURLC4EPKcPNS_13MemoryManagerE + 0x8c
> 10 libxerces-c.26.0.dylib 0x0156a278 xercesc_2_6::XMLURL::XMLURL(char
> const*, xercesc_2_6::MemoryManager*) + 0x10
> 11 intercomd 0x0003250c
> xml::DomParser::ParseURL(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&) + 0x310
> 12 intercomd 0x000cb384 weather::Parser::Update() + 0x3c4
> 13 intercomd 0x00098abc weather::Implementation::DoUpdate(bool, bool,
> bool) + 0x354
> 14 intercomd 0x000d3bdc weather::Thread::execute() + 0x69c
> 15 intercomd 0x00029054 util::Thread::run() + 0x38
> 16 intercomd 0x0002909c util::Thread::threadFunction(void*) + 0x34
> 17 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28
>
> Thread 3 Crashed:
> 0 libicucore.A.dylib 0x968d2208 ures_close + 0x18
> 1 libicucore.A.dylib 0x968e9fe8 ucol_close + 0xa8
> 2 ...ple.CoreServices.CarbonCore 0x902ce4c4 SetICUCollator + 0x30
> 3 ...ple.CoreServices.CarbonCore 0x902a4e58 UCCompareTextDefault +
> 0x98
> 4 libxerces-c.26.0.dylib 0x014f0e5c
> xercesc_2_6::MacOSUnicodeConverter::compareIString(unsigned short
> const*, unsigned short const*) + 0xc0
> 5 libxerces-c.26.0.dylib 0x01567174
> xercesc_2_6::XMLString::compareIString(unsigned short const*, unsigned
> short const*) + 0x40
> 6 libxerces-c.26.0.dylib 0x01569c48
> xercesc_2_6::XMLURL::lookupByName(unsigned short const*) + 0x3c
> 7 libxerces-c.26.0.dylib 0x0156c4dc
> xercesc_2_6::XMLURL::parse(unsigned short const*) + 0x284
> 8 libxerces-c.26.0.dylib 0x0156adc0
> xercesc_2_6::XMLURL::setURL(unsigned short const*) + 0x28
> 9 libxerces-c.26.0.dylib 0x0156a314
> _ZN11xercesc_2_66XMLURLC4EPKcPNS_13MemoryManagerE + 0x8c
> 10 libxerces-c.26.0.dylib 0x0156a278 xercesc_2_6::XMLURL::XMLURL(char
> const*, xercesc_2_6::MemoryManager*) + 0x10
> 11 intercomd 0x0003250c
> xml::DomParser::ParseURL(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&) + 0x310
> 12 intercomd 0x000b7838 rss::Parser::Parse(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&) + 0x314
> 13 intercomd 0x0008a834 rss::Implementation::DoUpdate() + 0x2d8
> 14 intercomd 0x000b9b48 rss::Thread::execute() + 0x5cc
> 15 intercomd 0x00029054 util::Thread::run() + 0x38
> 16 intercomd 0x0002909c util::Thread::threadFunction(void*) + 0x34
> 17 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Thread safety of MacOSUnicodeConverter::compareIString()?
Posted by Chris Cates <cc...@idlehands.net>.
I have an odd problem that I was wondering if anyone has seen before or
could maybe offer some input on.
I'm using xerces 2.6.0 on MacOS 10.3.7, and my application is
multi-threaded. There are two threads using xerces, each with its own
parser and associated data. I have seen a seg fault a couple times now
from these threads with identical stack traces on both of the xerces
threads. (Both threads stacks are included at the bottom from a single
crash.)
The only guess I've been able to come up with for what's going on is
that the Apple Carbon routine UCCompareTextDefault() is not
thread-safe. I was wondering if anyone has run into anything like this
before, or knows whether indeed, it may be a threading issue related to
the Apple routines.
Help? Thanks very much in advance.
-Chris
------------------------------
Thread 2 Crashed:
0 libicucore.A.dylib 0x968d2208 ures_close + 0x18
1 libicucore.A.dylib 0x968e9fe8 ucol_close + 0xa8
2 ...ple.CoreServices.CarbonCore 0x902ce4c4 SetICUCollator + 0x30
3 ...ple.CoreServices.CarbonCore 0x902a4e58 UCCompareTextDefault +
0x98
4 libxerces-c.26.0.dylib 0x014f0e5c
xercesc_2_6::MacOSUnicodeConverter::compareIString(unsigned short
const*, unsigned short const*) + 0xc0
5 libxerces-c.26.0.dylib 0x01567174
xercesc_2_6::XMLString::compareIString(unsigned short const*, unsigned
short const*) + 0x40
6 libxerces-c.26.0.dylib 0x01569c48
xercesc_2_6::XMLURL::lookupByName(unsigned short const*) + 0x3c
7 libxerces-c.26.0.dylib 0x0156c4dc
xercesc_2_6::XMLURL::parse(unsigned short const*) + 0x284
8 libxerces-c.26.0.dylib 0x0156adc0
xercesc_2_6::XMLURL::setURL(unsigned short const*) + 0x28
9 libxerces-c.26.0.dylib 0x0156a314
_ZN11xercesc_2_66XMLURLC4EPKcPNS_13MemoryManagerE + 0x8c
10 libxerces-c.26.0.dylib 0x0156a278
xercesc_2_6::XMLURL::XMLURL(char const*, xercesc_2_6::MemoryManager*) +
0x10
11 intercomd 0x0003250c
xml::DomParser::ParseURL(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&) + 0x310
12 intercomd 0x000cb384
weather::Parser::Update() + 0x3c4
13 intercomd 0x00098abc
weather::Implementation::DoUpdate(bool, bool, bool) + 0x354
14 intercomd 0x000d3bdc
weather::Thread::execute() + 0x69c
15 intercomd 0x00029054 util::Thread::run() +
0x38
16 intercomd 0x0002909c
util::Thread::threadFunction(void*) + 0x34
17 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28
Thread 3 Crashed:
0 libicucore.A.dylib 0x968d2208 ures_close + 0x18
1 libicucore.A.dylib 0x968e9fe8 ucol_close + 0xa8
2 ...ple.CoreServices.CarbonCore 0x902ce4c4 SetICUCollator + 0x30
3 ...ple.CoreServices.CarbonCore 0x902a4e58 UCCompareTextDefault +
0x98
4 libxerces-c.26.0.dylib 0x014f0e5c
xercesc_2_6::MacOSUnicodeConverter::compareIString(unsigned short
const*, unsigned short const*) + 0xc0
5 libxerces-c.26.0.dylib 0x01567174
xercesc_2_6::XMLString::compareIString(unsigned short const*, unsigned
short const*) + 0x40
6 libxerces-c.26.0.dylib 0x01569c48
xercesc_2_6::XMLURL::lookupByName(unsigned short const*) + 0x3c
7 libxerces-c.26.0.dylib 0x0156c4dc
xercesc_2_6::XMLURL::parse(unsigned short const*) + 0x284
8 libxerces-c.26.0.dylib 0x0156adc0
xercesc_2_6::XMLURL::setURL(unsigned short const*) + 0x28
9 libxerces-c.26.0.dylib 0x0156a314
_ZN11xercesc_2_66XMLURLC4EPKcPNS_13MemoryManagerE + 0x8c
10 libxerces-c.26.0.dylib 0x0156a278
xercesc_2_6::XMLURL::XMLURL(char const*, xercesc_2_6::MemoryManager*) +
0x10
11 intercomd 0x0003250c
xml::DomParser::ParseURL(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&) + 0x310
12 intercomd 0x000b7838
rss::Parser::Parse(std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&) + 0x314
13 intercomd 0x0008a834
rss::Implementation::DoUpdate() + 0x2d8
14 intercomd 0x000b9b48 rss::Thread::execute() +
0x5cc
15 intercomd 0x00029054 util::Thread::run() +
0x38
16 intercomd 0x0002909c
util::Thread::threadFunction(void*) + 0x34
17 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: macosx and sockets implementation question
Posted by Chris Cates <ca...@mac.com>.
Hi Alberto,
It is only for MacOS X; MacOS <=9 does not have sockets.
-Chris
On Dec 28, 2004, at 12:22 PM, Alberto Massari wrote:
> Hi Chris,
> I am not an expert on MacOS, but I was wondering if this change is
> only compatible with MacOS X; does MacOS 9 (and earlier) have support
> for BSD sockets?
>
> Alberto
>
> At 12.05 28/12/2004 -0600, Chris Cates wrote:
>
>> Since I haven't heard anything from anyone on the email below, I was
>> wondering if anyone would have an issue with me submitting the
>> following change:
>>
>> ====
>> //xerces-c-src_2_6_0/src/xercesc/util/Platforms/MacOS/
>> MacOSPlatformUtils.cpp ====
>> 78a79,80
>> > #elif defined(XML_USE_NETACCESSOR_SOCKET)
>> > #include <xercesc/util/NetAccessors/Socket/SocketNetAccessor.hpp>
>> 587a590,591
>> > #elif (defined(XML_USE_NETACCESSOR_SOCKET))
>> > return new SocketNetAccessor;
>>
>> Comments most welcome!
>> Thanks!
>> -Chris
>> ccates@idlehands.net
>>
>>
>> On Dec 8, 2004, at 12:38 PM, Chris Cates wrote:
>>>
>>> Greetings,
>>>
>>> I'm currently using xerces-c 2.6 built on MacOS X 10.3 with sockets
>>> as
>>> net access. (Which works very nicely, btw.)
>>>
>>> I was wondering why MacOSPlatformUtils' implementation of
>>> makeNetAccessor() does not create and return a SocketNetAccessor by
>>> default if it sees that the XML_USE_NETACCESSOR_SOCKET #define is
>>> set.
>>> I've tried this locally in my own build, and at first glance, it
>>> seems to work fine and save the user from setting fgNetAccessor
>>> manually when using sockets.
>>>
>>> Any reason this is not a part of the MacOSPlatformUtils by default?
>>> Is there something that I'm missing?
>>>
>>> Thanks!
>>> -Chris
>>> ccates@idlehands.net
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>>> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: macosx and sockets implementation question
Posted by Alberto Massari <am...@progress.com>.
Hi Chris,
I am not an expert on MacOS, but I was wondering if this change is only
compatible with MacOS X; does MacOS 9 (and earlier) have support for BSD
sockets?
Alberto
At 12.05 28/12/2004 -0600, Chris Cates wrote:
>Since I haven't heard anything from anyone on the email below, I was
>wondering if anyone would have an issue with me submitting the
>following change:
>
>====
>//xerces-c-src_2_6_0/src/xercesc/util/Platforms/MacOS/
>MacOSPlatformUtils.cpp ====
>78a79,80
> > #elif defined(XML_USE_NETACCESSOR_SOCKET)
> > #include <xercesc/util/NetAccessors/Socket/SocketNetAccessor.hpp>
>587a590,591
> > #elif (defined(XML_USE_NETACCESSOR_SOCKET))
> > return new SocketNetAccessor;
>
>Comments most welcome!
>Thanks!
>-Chris
>ccates@idlehands.net
>
>
>On Dec 8, 2004, at 12:38 PM, Chris Cates wrote:
>>
>>Greetings,
>>
>>I'm currently using xerces-c 2.6 built on MacOS X 10.3 with sockets as
>>net access. (Which works very nicely, btw.)
>>
>>I was wondering why MacOSPlatformUtils' implementation of
>>makeNetAccessor() does not create and return a SocketNetAccessor by
>>default if it sees that the XML_USE_NETACCESSOR_SOCKET #define is set.
>> I've tried this locally in my own build, and at first glance, it
>>seems to work fine and save the user from setting fgNetAccessor
>>manually when using sockets.
>>
>>Any reason this is not a part of the MacOSPlatformUtils by default?
>>Is there something that I'm missing?
>>
>>Thanks!
>>-Chris
>>ccates@idlehands.net
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>>For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: macosx and sockets implementation question
Posted by Chris Cates <cc...@idlehands.net>.
Excellent! Thanks very much, James.
-Chris
ccates@idlehands.net
On Dec 28, 2004, at 12:21 PM, James Berry wrote:
> Hey Chris,
>
> I guess I missed your first posting on this issue. No, there's no
> reason this should not be a part of the Mac OS port, and I'll try to
> get it in shortly. I've been meaning to get around to this myself.
> Thanks for the patch.
>
> -jdb
>
>
> On Dec 28, 2004, at 10:05 AM, Chris Cates wrote:
>> Since I haven't heard anything from anyone on the email below, I was
>> wondering if anyone would have an issue with me submitting the
>> following change:
>>
>> ====
>> //xerces-c-src_2_6_0/src/xercesc/util/Platforms/MacOS/
>> MacOSPlatformUtils.cpp ====
>> 78a79,80
>> > #elif defined(XML_USE_NETACCESSOR_SOCKET)
>> > #include <xercesc/util/NetAccessors/Socket/SocketNetAccessor.hpp>
>> 587a590,591
>> > #elif (defined(XML_USE_NETACCESSOR_SOCKET))
>> > return new SocketNetAccessor;
>>
>> Comments most welcome!
>> Thanks!
>> -Chris
>> ccates@idlehands.net
>>
>>
>> On Dec 8, 2004, at 12:38 PM, Chris Cates wrote:
>>
>>> Greetings,
>>>
>>> I'm currently using xerces-c 2.6 built on MacOS X 10.3 with sockets
>>> as net access. (Which works very nicely, btw.)
>>>
>>> I was wondering why MacOSPlatformUtils' implementation of
>>> makeNetAccessor() does not create and return a SocketNetAccessor by
>>> default if it sees that the XML_USE_NETACCESSOR_SOCKET #define is
>>> set. I've tried this locally in my own build, and at first glance,
>>> it seems to work fine and save the user from setting fgNetAccessor
>>> manually when using sockets.
>>>
>>> Any reason this is not a part of the MacOSPlatformUtils by default?
>>> Is there something that I'm missing?
>>>
>>> Thanks!
>>> -Chris
>>> ccates@idlehands.net
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>>> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: macosx and sockets implementation question
Posted by James Berry <jb...@apache.org>.
Hey Chris,
I guess I missed your first posting on this issue. No, there's no
reason this should not be a part of the Mac OS port, and I'll try to
get it in shortly. I've been meaning to get around to this myself.
Thanks for the patch.
-jdb
On Dec 28, 2004, at 10:05 AM, Chris Cates wrote:
> Since I haven't heard anything from anyone on the email below, I was
> wondering if anyone would have an issue with me submitting the
> following change:
>
> ====
> //xerces-c-src_2_6_0/src/xercesc/util/Platforms/MacOS/
> MacOSPlatformUtils.cpp ====
> 78a79,80
> > #elif defined(XML_USE_NETACCESSOR_SOCKET)
> > #include <xercesc/util/NetAccessors/Socket/SocketNetAccessor.hpp>
> 587a590,591
> > #elif (defined(XML_USE_NETACCESSOR_SOCKET))
> > return new SocketNetAccessor;
>
> Comments most welcome!
> Thanks!
> -Chris
> ccates@idlehands.net
>
>
> On Dec 8, 2004, at 12:38 PM, Chris Cates wrote:
>
>> Greetings,
>>
>> I'm currently using xerces-c 2.6 built on MacOS X 10.3 with sockets
>> as net access. (Which works very nicely, btw.)
>>
>> I was wondering why MacOSPlatformUtils' implementation of
>> makeNetAccessor() does not create and return a SocketNetAccessor by
>> default if it sees that the XML_USE_NETACCESSOR_SOCKET #define is
>> set. I've tried this locally in my own build, and at first glance, it
>> seems to work fine and save the user from setting fgNetAccessor
>> manually when using sockets.
>>
>> Any reason this is not a part of the MacOSPlatformUtils by default?
>> Is there something that I'm missing?
>>
>> Thanks!
>> -Chris
>> ccates@idlehands.net
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: macosx and sockets implementation question
Posted by Chris Cates <cc...@idlehands.net>.
Works great for me. Thanks very much!
-Chris
On Dec 28, 2004, at 1:09 PM, James Berry wrote:
> Patch committed. Thanks! Please verify.
>
> -jdb
>
>
> On Dec 28, 2004, at 10:05 AM, Chris Cates wrote:
>> Since I haven't heard anything from anyone on the email below, I was
>> wondering if anyone would have an issue with me submitting the
>> following change:
>>
>> ====
>> //xerces-c-src_2_6_0/src/xercesc/util/Platforms/MacOS/
>> MacOSPlatformUtils.cpp ====
>> 78a79,80
>> > #elif defined(XML_USE_NETACCESSOR_SOCKET)
>> > #include <xercesc/util/NetAccessors/Socket/SocketNetAccessor.hpp>
>> 587a590,591
>> > #elif (defined(XML_USE_NETACCESSOR_SOCKET))
>> > return new SocketNetAccessor;
>>
>> Comments most welcome!
>> Thanks!
>> -Chris
>> ccates@idlehands.net
>>
>>
>> On Dec 8, 2004, at 12:38 PM, Chris Cates wrote:
>>
>>> Greetings,
>>>
>>> I'm currently using xerces-c 2.6 built on MacOS X 10.3 with sockets
>>> as net access. (Which works very nicely, btw.)
>>>
>>> I was wondering why MacOSPlatformUtils' implementation of
>>> makeNetAccessor() does not create and return a SocketNetAccessor by
>>> default if it sees that the XML_USE_NETACCESSOR_SOCKET #define is
>>> set. I've tried this locally in my own build, and at first glance,
>>> it seems to work fine and save the user from setting fgNetAccessor
>>> manually when using sockets.
>>>
>>> Any reason this is not a part of the MacOSPlatformUtils by default?
>>> Is there something that I'm missing?
>>>
>>> Thanks!
>>> -Chris
>>> ccates@idlehands.net
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>>> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: macosx and sockets implementation question
Posted by James Berry <jb...@apache.org>.
Patch committed. Thanks! Please verify.
-jdb
On Dec 28, 2004, at 10:05 AM, Chris Cates wrote:
> Since I haven't heard anything from anyone on the email below, I was
> wondering if anyone would have an issue with me submitting the
> following change:
>
> ====
> //xerces-c-src_2_6_0/src/xercesc/util/Platforms/MacOS/
> MacOSPlatformUtils.cpp ====
> 78a79,80
> > #elif defined(XML_USE_NETACCESSOR_SOCKET)
> > #include <xercesc/util/NetAccessors/Socket/SocketNetAccessor.hpp>
> 587a590,591
> > #elif (defined(XML_USE_NETACCESSOR_SOCKET))
> > return new SocketNetAccessor;
>
> Comments most welcome!
> Thanks!
> -Chris
> ccates@idlehands.net
>
>
> On Dec 8, 2004, at 12:38 PM, Chris Cates wrote:
>
>> Greetings,
>>
>> I'm currently using xerces-c 2.6 built on MacOS X 10.3 with sockets
>> as net access. (Which works very nicely, btw.)
>>
>> I was wondering why MacOSPlatformUtils' implementation of
>> makeNetAccessor() does not create and return a SocketNetAccessor by
>> default if it sees that the XML_USE_NETACCESSOR_SOCKET #define is
>> set. I've tried this locally in my own build, and at first glance, it
>> seems to work fine and save the user from setting fgNetAccessor
>> manually when using sockets.
>>
>> Any reason this is not a part of the MacOSPlatformUtils by default?
>> Is there something that I'm missing?
>>
>> Thanks!
>> -Chris
>> ccates@idlehands.net
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: macosx and sockets implementation question
Posted by Scott Cantor <ca...@osu.edu>.
> Since I haven't heard anything from anyone on the email below, I was
> wondering if anyone would have an issue with me submitting the
> following change:
+1 from me, I lost a day to this missing code when I couldn't figure out
what the heck was happening.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: macosx and sockets implementation question
Posted by Chris Cates <cc...@idlehands.net>.
Since I haven't heard anything from anyone on the email below, I was
wondering if anyone would have an issue with me submitting the
following change:
====
//xerces-c-src_2_6_0/src/xercesc/util/Platforms/MacOS/
MacOSPlatformUtils.cpp ====
78a79,80
> #elif defined(XML_USE_NETACCESSOR_SOCKET)
> #include <xercesc/util/NetAccessors/Socket/SocketNetAccessor.hpp>
587a590,591
> #elif (defined(XML_USE_NETACCESSOR_SOCKET))
> return new SocketNetAccessor;
Comments most welcome!
Thanks!
-Chris
ccates@idlehands.net
On Dec 8, 2004, at 12:38 PM, Chris Cates wrote:
>
> Greetings,
>
> I'm currently using xerces-c 2.6 built on MacOS X 10.3 with sockets as
> net access. (Which works very nicely, btw.)
>
> I was wondering why MacOSPlatformUtils' implementation of
> makeNetAccessor() does not create and return a SocketNetAccessor by
> default if it sees that the XML_USE_NETACCESSOR_SOCKET #define is set.
> I've tried this locally in my own build, and at first glance, it
> seems to work fine and save the user from setting fgNetAccessor
> manually when using sockets.
>
> Any reason this is not a part of the MacOSPlatformUtils by default?
> Is there something that I'm missing?
>
> Thanks!
> -Chris
> ccates@idlehands.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org