yeah, my votes for thread safety are in order of importance:
object locking/unlocking (currently accessing an object variable can
cause a crash)
object alloc/dealloc (so we can construct and destory objects)
strings (you wouldn't believe the pain it is to write debug strs to
console using a struct and numbers :)
arrays (this may just be a problem with object locking/unlocking, but
i know they aren't safe currently)
framework items (my feelign is, if i can make objects and use all
intrinsic data types, i can declare to libc if i need to write a
file, or use a socket... all nice things - but not show stopper like
the above)
mike
--
Mike Woodworth
[EMAIL PROTECTED]
On Nov 9, 2006, at 9:41 AM, Daniel Stenning wrote:
Typo - meant to write:
For my current project I DONT need to make any calls to the
frameworks in
the code I would like threaded ( its a C++ parser and
translator ) . It is
all pretty much core RB language - ie no GUI calls, pretty just
arrays ,
strings, dictionaries and the folderItem, BinaryStream objects so
it would
be good to- at the very least make that sort of stuff thread safe
in RB.
I think that much ought to be achievable. For example, in the C++
world
there is a thread safe C++ string library available commercially.
On 9/11/06 13:44, "Daniel Stenning" <[EMAIL PROTECTED]> wrote:
For my current project I be make any calls to the frameworks in
the code I
would like threaded. It is all core RB language - no GUI calls,
pretty much
just arrays , strings and dictionaries and the folderitem,
BinaryStream
object ( its a C++ parser and translator ) so it would be good to-
at the
very least make that sort of stuff thread safe in RB.
I think that much ought to be achievable. I know for a fact there
is a
threaad safe C++ string library available commercially.
On 9/11/06 06:04, "Andy Dent" <[EMAIL PROTECTED]> wrote:
I'm with Daniel on this - do NOT underestimate the difficulties of
threading code.
On 09/11/2006, at 11:43 AM, Daniel L. Taylor wrote:
* I don't think we're ever going to see a fully preemptive-
thread safe
framework. Large parts of Win32, Carbon, and Cocoa are not thread
safe.
yep - I actually doubt this is something do-able. Transparently
making things thread-safe is *hard* computer science.
* For those thinking of jumping ship to Cocoa over this: having
done both, I
don't consider threading on Cocoa to be any easier than threading
on RB.
as someone who has written threaded programs in Cocoa, Windows and
WinCE, I agree entirely.
Useful articles in this Queue issue:
http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=332
Andy the thread-scarred (Pernese reference ;-)
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
