[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