@everybody (other than Phil who has already been most helpful):
I would really appreciate some timely help with my C++ questions.
Although, my (fairly elementary) C++ question below was initially
directed to Phil because he has been kind enough to answer such
questions from me before, if you have some C++ knowledge please don't
be hesitant about jumping in with your own answer to such questions.
After all, Phil is not available 24x7 (in fact he appears not to be
available at the moment) so if you do jump in with the answer, it
should help me reach my wxwidgets development goals much quicker than
if you don't.
And, by the way, this "jumping in" attitude should be encouraged in
general on this list if you have any relevant knowledge about the
question being discussed. So don't hold back out of some sense of
politeness that you are interrupting someone else's conversation.
@everybody (including Phil if someone else doesn't beat him to the
answer):
So to summarize the current status for _everybody_ here, gdb tells me
that calls to m_outputMemoryMap.getBuffer() and
m_outputMemoryMap.getswm() in, wxPLDevice::SetupMemoryMap obtains the
address of the buf char array and wsem in the shared memory shmbuf
struct without issues, and with the expected address 0x48 offset
between the two. However, a few steps later control passes to
PLNamedMutex::create, and the m_unamed_semaphore_MemoryMap version of
those calls produce incorrect addresses (0x48 for the first 0x0 for
the second). So why that difference considering that
m_unamed_semaphore_MemoryMap is defined in a similar way for the
PLNamedMutex class as m_outputMemoryMap is defined for the wxPLDevice
class?
I feel like I am on the edge of solving this, but I must be missing
something that should be obvious to someone knowledgeable in C++. From
these gdb results I now expect more has to be done than the single statement
PLMemoryMap m_unamed_semaphore_MemoryMap;
(see diff below) to set up access to the PLMemoryMap class methods from the
PLNamedMutex class.
But what is that "more"?
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
---------- Forwarded message ----------
Date: Sun, 5 Feb 2017 02:18:28 -0800 (PST)
From: Alan W. Irwin <ir...@beluga.phys.uvic.ca>
To: Phil Rosenberg <p.d.rosenb...@gmail.com>,
PLplot development list <Plplot-devel@lists.sourceforge.net>
Subject: [Plplot-devel] C++ help requested for step 1.
On 2017-02-04 19:41-0800 Alan W. Irwin wrote:
> 1. Make the current one-semaphore approach work with unnamed
> semaphores. The last commit put essentially all the infrastructure in
> place to support this further change so this change should be a simple
> matter of replacing (for this case) the calls to sem_open and
> sem_close with sem_init and sem_destroy, and the rest of the current
> one-semaphore code should work as is along with the mutex and sleep
> API calls required by this method.
Hi Phil:
I need some help on another C++ issue which should be simple to figure
out.
I got the first pass at the coding done for (1) (see the diff
below relative to current git master), and it builds without issues,
but it is not working properly at run time. The problem is (according
to gdb) that
m_mutex = m_unamed_semaphore_MemoryMap.getwsem();
assigns a NULL pointer to m_mutex which leads to an immediate segfault
for the subsequent sem_init(m_mutex, 1, 1);
Can you give me the C++ help to figure out why this simple getwsem method is
returning
a NULL pointer rather than the address of wsem (an unnamed semaphore) within
the shared
memory struct as intended?
Alan
diff --git a/drivers/wxwidgets_comms.cpp b/drivers/wxwidgets_comms.cpp
index 6b5c071..dfb607c 100644
--- a/drivers/wxwidgets_comms.cpp
+++ b/drivers/wxwidgets_comms.cpp
@@ -1,4 +1,5 @@
-// Copyright (C) 2015 Phil Rosenberg
+// Copyright (C) 2015-2017 Phil Rosenberg
+// Copyright (C) 2017 Alan W. Irwin
//
// This file is part of PLplot.
//
@@ -171,6 +172,12 @@ void PLNamedMutex::create( const char *name, bool
aquireOnCreate )
{
#ifdef WIN32
m_mutex = CreateMutexA( NULL, aquireOnCreate ? TRUE : FALSE, name );
+#elif defined(PL_HAVE_UNNAMED_POSIX_SEMAPHORES)
+ if ( !isValid() )
+ {
+ m_mutex = m_unamed_semaphore_MemoryMap.getwsem();
+ sem_init(m_mutex, 1, 1);
+ }
#else
m_mutex = NULL;
char mutexName[251];
@@ -232,6 +239,8 @@ void PLNamedMutex::clear()
release();
#ifdef WIN32
CloseHandle( m_mutex );
+#elif defined(PL_HAVE_UNNAMED_POSIX_SEMAPHORES)
+ sem_destroy( m_mutex );
#else
sem_close( m_mutex );
#endif
diff --git a/drivers/wxwidgets_comms.h b/drivers/wxwidgets_comms.h
index a6798ee..90a9be8 100644
--- a/drivers/wxwidgets_comms.h
+++ b/drivers/wxwidgets_comms.h
@@ -100,6 +100,7 @@ public:
bool isValid() { return m_buffer != NULL; }
#ifdef PL_HAVE_UNNAMED_POSIX_SEMAPHORES
char *getBuffer() { return ( (shmbuf *) m_buffer )->buf; }
+ sem_t *getwsem() { return & ( ( (shmbuf *) m_buffer )->wsem); }
size_t getSize() { return PL_SHARED_ARRAY_SIZE; }
#else
char *getBuffer() { return (char *) m_buffer; }
@@ -134,6 +135,9 @@ private:
bool m_haveLock;
#ifdef WIN32
HANDLE m_mutex;
+#elif defined(PL_HAVE_UNNAMED_POSIX_SEMAPHORES)
+ PLMemoryMap m_unamed_semaphore_MemoryMap;
+ sem_t * m_mutex;
#else
sem_t * m_mutex;
#endif
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
