public inbox for ecos-patches@sourceware.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-patches@ecos.sourceware.org
Subject: [Bug 1001544] services/curses/pdcurses: porting to GCC 4.6
Date: Mon, 26 Mar 2012 16:11:00 -0000	[thread overview]
Message-ID: <20120326161109.4F08A2F78003@mail.ecoscentric.com> (raw)
In-Reply-To: <bug-1001544-104@http.bugs.ecos.sourceware.org/>

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

--- Comment #3 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-26 17:11:07 BST ---
(In replay in comment #2)
> As a patch to the current code, it is fine, please commit.

Thanks for review, I'll process it.

> 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.

You're absolutely right. In those days I did not know that PDCurses is
not thread safe (though and that serial driver is not thread-safe too).
And now I even found a separate record about (in PDCurses HISTORY file)

 - Removed the PDC_THREAD_BUILD stuff, which has never worked. For the
   record: PDCurses is not thread-safe. Neither is ncurses; and the
   X/Open curses spec explicitly makes it a non-requirement.

> 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.

I think it is better to remove that `example' folder, which can mislead
someone else. So, I would remove that example in the next commit.  I see
that native PDcurses demos (or eCos PDCurses tests) are more than enough
for the package.

Thank you for your all points.

Sergei

> Jifl

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

  parent reply	other threads:[~2012-03-26 16:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-24 11:31 [Bug 1001544] New: " bugzilla-daemon
2012-03-25 16:35 ` [Bug 1001544] " bugzilla-daemon
2012-03-26 14:31 ` bugzilla-daemon
2012-03-26 16:11 ` bugzilla-daemon [this message]
2012-03-26 19:13 ` bugzilla-daemon
2012-03-29 18:44 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120326161109.4F08A2F78003@mail.ecoscentric.com \
    --to=bugzilla-daemon@bugs.ecos.sourceware.org \
    --cc=ecos-patches@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).