[Bordeaux-threads-devel] Basically, I suck (LW patch)
Matt Lamari
matt.lamari at gmail.com
Wed Aug 12 22:23:21 UTC 2009
Okay - I changed thread-alive-p in the attached file; (but I did not
write the original).
The hash-table modification has now been shifted out of process-wait.
The lock is now returned on an unwind-protect around the entire
function's body (in case anything else fails) -.
The tlist-affecting functions have been factored out into other
functions, and indenting was fixed.
Condition-notify's primary failure clause has been cleaned up, and made
more correct (it now checks for consumption of the notification as
independent of receiving it).
Martin - thanks for correcting this with respect to Lispworks, please
let me know if anything else looks amiss.
Everybody else - look, I'm a windows guy and am not too up on darcs or
unix diff files - but my change is a big addition to a file that doesn't
see a lot of use. Please diff and add from the attached file.
Martin Simmons wrote:
>>>>>> On Tue, 11 Aug 2009 00:26:39 +0200, Stelian Ionescu said:
>>>>>>
>> On Sat, 2009-08-01 at 18:46 -0500, Matt Lamari wrote:
>>
>>> I'm still around if anyone needs support on the functions I've added.
>>>
>> I've cleaned up the code a little(attached as patch against the darcs
>> repository), however, before merging I need you to split condition-wait
>> in at least 3-4 separate functions because it's way too big(two
>> screenfuls here). When you're done, please send a unified diff done
>> against the darcs repository.
>>
>
> I have some comments on the patch:
>
> It would be better to implement thread-alive-p by calling mp:process-alive-p.
>
> The relocking of the caller's lock in condition-wait should be inside the
> unwind-protect cleanup, otherwise you can throw without the lock held.
>
> Claiming a lock and doing hash table manipulation inside a mp:process-wait
> predicate ("Waiting for notification") is not good practice because the
> predicate is suppose to be a pure function. It should be safe to check the
> value of wakeup-allowed-to-proceed without the lock and manipulate the hash
> table after mp:process-wait has returned.
>
> Is the prog1 in condition-wait redundant?
>
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lispworks.lisp
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20090812/2a4c44b1/attachment.ksh>
More information about the bordeaux-threads-devel
mailing list