You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It doesn't really make any sense for these objects to be shared.
They contain API methods which are only intended for the parent thread to use, such as start(), join(), isRunning(), isJoined(), etc.
The only reason a shared context object is desirable for these things is to allow Thread::run() to get information from the parent thread.
After the initial run(), it makes more sense to put things in static properties, rather than paying a performance penalty to access them from the thread context again and again.
Proposal:
Make Thread and Worker no longer extend ThreadSafe
Make Thread and Worker become final
Make Thread accept a Runnable in its __construct() (which will be thread-safe), which it runs and then immediately shuts itself down (contrary to a Worker, which remains running - though we could easily ditch Thread and only have Worker with this system)
Possibly introduce ClosureRunnable
Move Thread::getCreatorId() to Runnable::getCreatorId()
Remove Thread::getCurrentThread() and Thread->getThreadId() (Thread::getCurrentThreadId() will remain)
It doesn't really make any sense for these objects to be shared.
They contain API methods which are only intended for the parent thread to use, such as
start()
,join()
,isRunning()
,isJoined()
, etc.The only reason a shared context object is desirable for these things is to allow
Thread::run()
to get information from the parent thread.After the initial
run()
, it makes more sense to put things in static properties, rather than paying a performance penalty to access them from the thread context again and again.Proposal:
Thread
andWorker
no longer extendThreadSafe
Thread
andWorker
becomefinal
Thread
accept aRunnable
in its__construct()
(which will be thread-safe), which it runs and then immediately shuts itself down (contrary to aWorker
, which remains running - though we could easily ditchThread
and only haveWorker
with this system)ClosureRunnable
Thread::getCreatorId()
toRunnable::getCreatorId()
Thread::getCurrentThread()
andThread->getThreadId()
(Thread::getCurrentThreadId()
will remain)Thread::getName()
andThread::setName()
for identification (relates to API to set thread name seen by htop etc #139)The text was updated successfully, but these errors were encountered: