This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001544] services/curses/pdcurses: porting to GCC 4.6


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001544

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com

--- Comment #2 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-26 15:31:15 BST ---
As a patch to the current code, it is fine, please commit.

This is a separate issue really, but when I looked at it, I thought "that isn't
thread-safe". But then I saw that it wasn't thread-safe before either, and then
I saw that the main pdcurses code isn't thread-safe either. So I thought,
that's fine, it's not meant to be thread-safe, although that isn't clear in the
documentation.

But then I see examples/pdcecos_app.c which seems to create a bunch of threads.
But if curses isn't thread-safe, that doesn't seem like a great idea.

In fact I don't really understand the purpose of pdcecos_app.c - why would
users need to start curses threads in a special and unusual way? If it's just
because of the need to create a per-thread data index, then there are other
ways that could be dealt with.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]